drivers/platform/surface/surface_acpi_notify.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.
This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.
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")
This change adds a new WQ_PERCPU flag to explicitly request
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.
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
---
drivers/platform/surface/surface_acpi_notify.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/surface/surface_acpi_notify.c b/drivers/platform/surface/surface_acpi_notify.c
index 3b30cfe3466b..a9dcb0bbe90e 100644
--- a/drivers/platform/surface/surface_acpi_notify.c
+++ b/drivers/platform/surface/surface_acpi_notify.c
@@ -862,7 +862,7 @@ static int __init san_init(void)
{
int ret;
- san_wq = alloc_workqueue("san_wq", 0, 0);
+ san_wq = alloc_workqueue("san_wq", WQ_PERCPU, 0);
if (!san_wq)
return -ENOMEM;
ret = platform_driver_register(&surface_acpi_notify);
--
2.51.1
On Fri, 7 Nov 2025, Marco Crivellari wrote:
> Currently if a user enqueues a work item using schedule_delayed_work() the
> used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
> WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
> schedule_work() that is using system_wq and queue_work(), that makes use
> again of WORK_CPU_UNBOUND.
> This lack of consistency cannot be addressed without refactoring the API.
>
> alloc_workqueue() treats all queues as per-CPU by default, while unbound
> workqueues must opt-in via WQ_UNBOUND.
>
> This default is suboptimal: most workloads benefit from unbound queues,
> allowing the scheduler to place worker threads where they’re needed and
> reducing noise when CPUs are isolated.
>
> 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")
>
> This change adds a new WQ_PERCPU flag to explicitly request
> 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.
>
> Once migration is complete, WQ_UNBOUND can be removed and unbound will
> become the implicit default.
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!?!
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).
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.
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 ;-)).
--
i.
> Suggested-by: Tejun Heo <tj@kernel.org>
> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
> ---
> drivers/platform/surface/surface_acpi_notify.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/platform/surface/surface_acpi_notify.c b/drivers/platform/surface/surface_acpi_notify.c
> index 3b30cfe3466b..a9dcb0bbe90e 100644
> --- a/drivers/platform/surface/surface_acpi_notify.c
> +++ b/drivers/platform/surface/surface_acpi_notify.c
> @@ -862,7 +862,7 @@ static int __init san_init(void)
> {
> int ret;
>
> - san_wq = alloc_workqueue("san_wq", 0, 0);
> + san_wq = alloc_workqueue("san_wq", WQ_PERCPU, 0);
> if (!san_wq)
> return -ENOMEM;
> ret = platform_driver_register(&surface_acpi_notify);
>
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?
"
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")
For more details see the Link tag below.
This change adds a new WQ_PERCPU flag to explicitly request
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.
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
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!
--
Marco Crivellari
L3 Support Engineer, Technology & Product
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.
On Tue, Nov 18, 2025 at 3:43 PM Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> 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.
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.
In order to keep alloc_workqueue() behavior identical, explicitly request
WQ_PERCPU.
If it sounds good I will send the v2.
Thanks!
--
Marco Crivellari
L3 Support Engineer, Technology & Product
On Wed, 19 Nov 2025, Marco Crivellari wrote:
> On Tue, Nov 18, 2025 at 3:43 PM Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> 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.
On Wed, Nov 19, 2025 at 11:38 AM Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
> [...]
> 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.
Yes, it makes sense. I changed that part.
This is the updated version:
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 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.
In order to keep alloc_workqueue() behavior identical, explicitly request
WQ_PERCPU.
Thanks!
--
Marco Crivellari
L3 Support Engineer, Technology & Product
On Wed, 19 Nov 2025, Marco Crivellari wrote:
> On Wed, Nov 19, 2025 at 11:38 AM Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> > [...]
> > 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.
>
> Yes, it makes sense. I changed that part.
>
> This is the updated version:
>
> 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 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.
>
> In order to keep alloc_workqueue() behavior identical, explicitly request
> WQ_PERCPU.
Fine with me, thanks.
For those system_wq changes you can follow a similar structure but alter
it to match what is changed in the other interface.
This seems already okay:
"Replace system_wq with system_percpu_wq, keeping the same behavior."
And again you can drop the old system_wq is kept for a while thing, it's
irrelevant to those changes as they're no longer using the system_wq.
(When sending the update, you can send all three drivers/platform/ changes
in a single series.)
--
i.
Hi,
On Wed, Nov 19, 2025 at 12:12 PM Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
>[...]
>
> For those system_wq changes you can follow a similar structure but alter
> it to match what is changed in the other interface.
>
> This seems already okay:
>
> "Replace system_wq with system_percpu_wq, keeping the same behavior."
Sorry it's just to check with you before sending a useless series.
Sounds good this, for the 2 system_percpu_wq commit logs?
I don't think there is more to add here, because it is a wq rename.
This patch continues the effort to refactor worqueue APIs, which has begun
with the change 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")
For more details see the Link tag below. Replace system_wq with
system_percpu_wq, keeping the same behavior.
Thanks!
--
Marco Crivellari
L3 Support Engineer, Technology & Product
On Wed, 19 Nov 2025, Marco Crivellari wrote:
> Hi,
> On Wed, Nov 19, 2025 at 12:12 PM Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> >[...]
> >
> > For those system_wq changes you can follow a similar structure but alter
> > it to match what is changed in the other interface.
> >
> > This seems already okay:
> >
> > "Replace system_wq with system_percpu_wq, keeping the same behavior."
>
> Sorry it's just to check with you before sending a useless series.
> Sounds good this, for the 2 system_percpu_wq commit logs?
> I don't think there is more to add here, because it is a wq rename.
>
>
> This patch continues the effort to refactor worqueue APIs, which has begun
Please fix that typo.
> with the change 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")
You should still have here the paragraph which explains the default change
briefly, similar to what was with the WQ_PERCPU description. I suggest you
just edit the wording in the paragraph taken from WQ_PERCPU changelog we
agreed on at the places where functions and arguments are different.
> For more details see the Link tag below. Replace system_wq with
> system_percpu_wq, keeping the same behavior.
>
>
> Thanks!
>
>
--
i.
Le Wed, Nov 19, 2025 at 04:44:32PM +0200, Ilpo Järvinen a écrit :
> On Wed, 19 Nov 2025, Marco Crivellari wrote:
>
> > Hi,
> > On Wed, Nov 19, 2025 at 12:12 PM Ilpo Järvinen
> > <ilpo.jarvinen@linux.intel.com> wrote:
> > >[...]
> > >
> > > For those system_wq changes you can follow a similar structure but alter
> > > it to match what is changed in the other interface.
> > >
> > > This seems already okay:
> > >
> > > "Replace system_wq with system_percpu_wq, keeping the same behavior."
> >
> > Sorry it's just to check with you before sending a useless series.
> > Sounds good this, for the 2 system_percpu_wq commit logs?
> > I don't think there is more to add here, because it is a wq rename.
> >
> >
> > This patch continues the effort to refactor worqueue APIs, which has begun
>
> Please fix that typo.
>
> > with the change 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")
>
> You should still have here the paragraph which explains the default change
> briefly, similar to what was with the WQ_PERCPU description. I suggest you
> just edit the wording in the paragraph taken from WQ_PERCPU changelog we
> agreed on at the places where functions and arguments are different.
Thanks Ilpo for your changelogs change suggestions!
How does the following look like?
"""
platform: x86: Replace use of system_wq with system_percpu_wq
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 after a careful review and conversion of each individual
case, workqueue users must be converted to the better named new workqueues with
no intended behaviour changes:
system_wq -> system_percpu_wq
system_unbound_wq -> systemd_dfl_wq
This way the old obsolete workqueues (system_wq, system_unbound_wq) can be
removed in the future.
"""
--
Frederic Weisbecker
SUSE Labs
On Wed, Nov 19, 2025 at 12:12 PM Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote: > [...] > Fine with me, thanks. > > > For those system_wq changes you can follow a similar structure but alter > it to match what is changed in the other interface. > > This seems already okay: > > "Replace system_wq with system_percpu_wq, keeping the same behavior." > > And again you can drop the old system_wq is kept for a while thing, it's > irrelevant to those changes as they're no longer using the system_wq. > > > (When sending the update, you can send all three drivers/platform/ changes > in a single series.) Perfect, many thanks! -- Marco Crivellari L3 Support Engineer, Technology & Product
© 2016 - 2025 Red Hat, Inc.