On Thu, 2026-01-08 at 14:45 +0100, Marco Crivellari wrote: > On Thu, Jan 8, 2026 at 2:29 PM Rodrigo Vivi <[email protected]> > wrote: > > I'm sorry for the delay here, but could you please refactor this > > commit > > message? > > > > The first part of this commit message is the true justification for > > your > > original work, not for this patch here. > > Hi Rodrigo, > > Sure, I already have a new version of it: > > --- > > This patch continues the effort to refactor workqueue APIs, which has > begun > with the changes introducing new workqueues and a new alloc_workqueue > flag: > > commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and > system_dfl_wq") > commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") > > The point of the refactoring is to eventually alter the default > behavior of > workqueues to become unbound by default so that their workload > placement is > optimized by the scheduler. > > Before that to happen, workqueue users must be converted to the > better named > new workqueues with no intended behaviour changes: > > system_wq -> system_percpu_wq > system_unbound_wq -> system_dfl_wq > > This way the old obsolete workqueues (system_wq, system_unbound_wq) > can be > removed in the future. > > > > Except for your last phrase, which indicates, some wish of removing > > the unbound_wq, it doesn't state clear on why we should change the > > unbound per the dfl (default?). > > > > Perhaps the authors of these cases below wanted to be unbound, > > but choosing the default will make us to be tied to whatever > > default might become in the future. > > > > Right now both unbound and dfl are identical. In the future > > you are planning to remove the unbound, but what about the dfl? > > Any plans or possible changes? If no change is planned to dfl, > > why create default and simply not stay with the unbound one > > that is much more clear on its intention? > > Yes, "dfl" is "default". > > With the new version above I think it is clear, but in short: the > rename > is needed as a first refactoring step; the plan is to have an unbound > workqueue > as default. > > system_unbound_wq will be removed and changed with system_dfl_wq. > system_dfl_wq is the new unbound workqueue, it works exactly the same > as > system_unbound_wq. > > system_wq will be replaced with system_percpu_wq; same thing as > above, > no behavioral changes, system_percpu_wq is the new per-cpu workqueue. > > This is to make clear that if a per-cpu workqueue is not needed, the > correct > choice is system_dfl_wq. > > Also, during this conversion phase, I can tell many subsystems asked > to > change system_wq (the name of the "old" per-cpu workqueue) with > system_dfl_wq, because they just wanted to use a system workqueue and > thought system_wq was already the unbound one. > > All of this work has been discussed here: > > https://lore.kernel.org/all/[email protected]/ > > I will add this Link to the above commit log. Let me know if it > sounds good.
This is perfect, thank you! > > Thanks!
