linux-kernel - Re: [PATCH v2 1/2] drm/xe: replace use of system_unbound_wq with system_dfl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAofZF4_uV+78JWq2FLaezv4qaVK7BiyVLXmXNtaPXB_jhvDYQ@mail.gmail.com>
Date: Thu, 8 Jan 2026 14:45:05 +0100
From: Marco Crivellari <marco.crivellari@...e.com>
To: Rodrigo Vivi <rodrigo.vivi@...el.com>
Cc: linux-kernel@...r.kernel.org, intel-xe@...ts.freedesktop.org, 
	dri-devel@...ts.freedesktop.org, Tejun Heo <tj@...nel.org>, 
	Lai Jiangshan <jiangshanlai@...il.com>, Frederic Weisbecker <frederic@...nel.org>, 
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>, Michal Hocko <mhocko@...e.com>, 
	Lucas De Marchi <lucas.demarchi@...el.com>, 
	Thomas Hellstrom <thomas.hellstrom@...ux.intel.com>, David Airlie <airlied@...il.com>, 
	Simona Vetter <simona@...ll.ch>
Subject: Re: [PATCH v2 1/2] drm/xe: replace use of system_unbound_wq with system_dfl_wq

On Thu, Jan 8, 2026 at 2:29 PM Rodrigo Vivi <rodrigo.vivi@...el.com> 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/20250221112003.1dSuoGyc@linutronix.de/

I will add this Link to the above commit log. Let me know if it sounds good.

Thanks!

-- 

Marco Crivellari

L3 Support Engineer