[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 03/30] Lazy percpu counters
- To: Steven Rostedt <rostedt@xxxxxxxxxxx>
- From: Kent Overstreet <kent.overstreet@xxxxxxxxx>
- Date: Thu, 1 Sep 2022 11:43:21 -0400
- Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Suren Baghdasaryan <surenb@xxxxxxxxxx>, akpm@xxxxxxxxxxxxxxxxxxxx, mhocko@xxxxxxxx, vbabka@xxxxxxx, hannes@xxxxxxxxxxx, roman.gushchin@xxxxxxxxx, mgorman@xxxxxxx, dave@xxxxxxxxxxxx, willy@xxxxxxxxxxxxx, liam.howlett@xxxxxxxxxx, void@xxxxxxxxxxxxx, juri.lelli@xxxxxxxxxx, ldufour@xxxxxxxxxxxxx, peterx@xxxxxxxxxx, david@xxxxxxxxxx, axboe@xxxxxxxxx, mcgrof@xxxxxxxxxx, masahiroy@xxxxxxxxxx, nathan@xxxxxxxxxx, changbin.du@xxxxxxxxx, ytcoode@xxxxxxxxx, vincent.guittot@xxxxxxxxxx, dietmar.eggemann@xxxxxxx, bsegall@xxxxxxxxxx, bristot@xxxxxxxxxx, vschneid@xxxxxxxxxx, cl@xxxxxxxxx, penberg@xxxxxxxxxx, iamjoonsoo.kim@xxxxxxx, 42.hyeyoo@xxxxxxxxx, glider@xxxxxxxxxx, elver@xxxxxxxxxx, dvyukov@xxxxxxxxxx, shakeelb@xxxxxxxxxx, songmuchun@xxxxxxxxxxxxx, arnd@xxxxxxxx, jbaron@xxxxxxxxxx, rientjes@xxxxxxxxxx, minchan@xxxxxxxxxx, kaleshsingh@xxxxxxxxxx, kernel-team@xxxxxxxxxxx, linux-mm@xxxxxxxxx, iommu@xxxxxxxxxxxxxxx, kasan-dev@xxxxxxxxxxxxxxxx, io-uring@xxxxxxxxxxxxxxx, linux-arch@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, linux-bcache@xxxxxxxxxxxxxxx, linux-modules@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
- Delivery-date: Thu, 01 Sep 2022 15:43:37 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Thu, Sep 01, 2022 at 10:48:39AM -0400, Steven Rostedt wrote:
> On Thu, 1 Sep 2022 10:32:19 -0400
> Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote:
>
> > On Thu, Sep 01, 2022 at 08:51:31AM +0200, Peter Zijlstra wrote:
> > > On Tue, Aug 30, 2022 at 02:48:52PM -0700, Suren Baghdasaryan wrote:
> > > > +static void lazy_percpu_counter_switch_to_pcpu(struct
> > > > raw_lazy_percpu_counter *c)
> > > > +{
> > > > + u64 __percpu *pcpu_v = alloc_percpu_gfp(u64,
> > > > GFP_ATOMIC|__GFP_NOWARN);
> > >
> > > Realize that this is incorrect when used under a raw_spinlock_t.
> >
> > Can you elaborate?
>
> All allocations (including GFP_ATOMIC) grab normal spin_locks. When
> PREEMPT_RT is configured, normal spin_locks turn into a mutex, where as
> raw_spinlock's do not.
>
> Thus, if this is done within a raw_spinlock with PREEMPT_RT configured, it
> can cause a schedule while holding a spinlock.
Thanks, I think we should be good here but I'll document it anyways.
|
