Re: [PATCH] platform/surface: acpi-notify: add WQ_PERCPU to alloc_workqueue users

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 3404 bytes --]

On Tue, 18 Nov 2025, Marco Crivellari wrote:

> Hi,
> 
> On Tue, Nov 18, 2025 at 12:30 PM Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> > [...]
> > Hi,
> >
> > There's lots of words in this but it's extremely confusingly written.
> >
> > On one hand, you're saying "most workloads benefit from unbound queues"
> > but then end up using percpu anyway in the actual diff!?!
> 
> Yes, to keep the same behavior.
> There are subsystems who are asked to convert the workqueue to unbound.
> So in this case I will send the v2 with the change.
> 
> > If this is to support refactoring efforts, start the
> > description/justification in the changelog with that, with only a concise
> > explanation of the refactoring goal (you don't need to explain everything
> > that is already in the changelogs of the commits you refer above).
> 
> It makes sense.
> 
> > And I'd expect explanation to the forementioned inconsistency, it might be
> > because of the refactoring in steps. But if that's the case, you should
> > instead mention that either a) there will be a follow-up to migrate to
> > unbound where applicable (assuming it cannot be done now) or b) state
> > that this change is just to keep behavior the same and each case needs to
> > be evaluated once the refactoring is complete whether unbound could be
> > used or not.
> 
> What do you think, is it better in this way?

Still quite non-specific to this particular change.

> "
> This continues the effort to refactor workqueue APIs, which began with
> the introduction of new workqueues and a new alloc_workqueue flag in:
> 
> commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
> commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
> 

The refactoring is going to alter the default behavior of ...
[*].

> For more details see the Link tag below.



> This change adds a new WQ_PERCPU flag to explicitly request

This change doesn't add a new flag, "explicitly request" part is correct 
though but as written things are mixed up.

I'd just replace this paragraph and the next with something much simpler 
and more to the point:

"In order to keep alloc_workqueue() behavior identical, explicitly request 
WQ_PERCPU."

> alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.
>
> With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
> any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
> must now use WQ_PERCPU.

This belongs earlier to description of the refactoring (to [*]).

> Once migration is complete, WQ_UNBOUND can be removed and unbound will
> become the implicit default.

This is irrelevant detail about refactoring since WQ_PERCPU is used here.

> Suggested-by: Tejun Heo <tj@kernel.org>
> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
> Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/
> "
> 
> The Link is the original upstream discussion with all the details.
> I think adding more details here will be too much (and unrelated with the
> work itself).
> 
> > Also, there's one copy-pasted typo "worqueue" in the other patches
> > relating to pdx86 (and likely all your other copy-pasted
> > descriptions to other subsystems than pdx86 ;-)).
> 
> Uh, I completely missed that!
> 
> Thanks!
> 

-- 
 i.