Re: [PATCH 1/4] Introducing qpw_lock() and per-cpu queue & flush work

[Leonardo Bras <leobras.c@gmail.com>]

On Wed, Feb 11, 2026 at 09:09:02AM -0300, Marcelo Tosatti wrote:
> Hi Leonardo,
> 
> On Fri, Feb 06, 2026 at 09:16:36PM -0300, Leonardo Bras wrote:
> > > ===================================================================
> > > --- slab.orig/MAINTAINERS
> > > +++ slab/MAINTAINERS
> > > @@ -21291,6 +21291,12 @@ F:	Documentation/networking/device_drive
> > >  F:	drivers/bus/fsl-mc/
> > >  F:	include/uapi/linux/fsl_mc.h
> > >  
> > > +QPW
> > > +M:	Leonardo Bras <leobras@redhat.com>
> > 
> > Thanks for keeping that up :)
> > Could you please change this line to 
> > 
> > +M:	Leonardo Bras <leobras.c@gmail.com>
> > 
> > As I don't have access to Red Hat's mail anymore.
> > The signoffs on each commit should be fine to keep :)
> 
> Done.
> 
> > 
> > > +S:	Supported
> > > +F:	include/linux/qpw.h
> > > +F:	kernel/qpw.c
> > > +
> > 
> > Should we also add the Documentation file as well?
> > 
> > +F:	Documentation/locking/qpwlocks.rst
> 
> Done.
> 
> > > +The queue work related functions (analogous to queue_work_on and flush_work) are:
> > > +queue_percpu_work_on and flush_percpu_work.
> > > +
> > > +The behaviour of the QPW functions is as follows:
> > > +
> > > +* !CONFIG_PREEMPT_RT and !CONFIG_QPW (or CONFIG_QPW and qpw=off kernel
> > 
> > I don't think PREEMPT_RT is needed here (maybe it was copied from the 
> > previous QPW version which was dependent on PREEMPT_RT?)
> 
> Ah, OK, my bad. Well, shouldnt CONFIG_PREEMPT_RT select CONFIG_QPW and
> CONFIG_QPW_DEFAULT=y ?

Oh, I sure think it should, even if not doing so at the current patchset.

But my point in above comment is that even if it did, there was no need to 
mention !RT and !QPW, as RT would select QPW, so you only need to mention 
QPW :)

Before QPW having it's own CONFIG_ I was using RT to compile this in, so 
maybe that's why the previous version of the cover letter mentioned it. :\

Thanks!
Leo