On Wed, 19 Nov 2025, Marco Crivellari wrote: > On Tue, Nov 18, 2025 at 3:43 PM Ilpo Järvinen > wrote: > > [...] > > > 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. > > Thanks for the suggestions, I think it should be ok now: > > 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 > alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified. This looks still wrong! In 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") you write: "WQ_UNBOUND can be removed and unbound will become the implicit default". So after refactoring, WQ_UNBOUND cannot be specified as it has been removed AND the default behavior is "unbound", not "per-cpu", right? So it should be other way around, e.g.: The refactoring is going to alter the behavior of alloc_workqueue() to be unbound by default. > 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. > For more details see the Link tag below. Please reflow the paragraphs normally (no mid-paragraph short lines). > > In order to keep alloc_workqueue() behavior identical, explicitly request > WQ_PERCPU. > > > If it sounds good I will send the v2. -- i.