mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Marco Crivellari <marco.crivellari@suse.com>
Cc: linux-kernel@vger.kernel.org,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Michal Hocko <mhocko@suse.com>
Subject: Re: [PATCH 0/4] Workqueue: replace system wq and change alloc_workqueue callers
Date: Thu, 21 Aug 2025 10:29:35 -1000	[thread overview]
Message-ID: <aKeBr3eBfh0wr_fH@slm.duckdns.org> (raw)
In-Reply-To: <CAAofZF7gEeKVWf_i3uCj=QPNpDXmunb30_6MqiXRHbb9wGHKCQ@mail.gmail.com>

Hello,

On Thu, Aug 21, 2025 at 09:40:58AM +0200, Marco Crivellari wrote:
> > On Tue, Aug 19, 2025 at 02:28:12PM +0200, Marco Crivellari wrote:
> > > Another question / observation: I guess maintainers can't just pull
> > > the changes and merge for the next release, if the workqueue changes
> > > (e.g. changes in queue_work() etc) are not also merged, right?
> > >
> > > I received a reply here, in the meantime, in "Workqueue: fs: replace
> > > use of system_wq and add WQ_PERCPU to alloc_workqueue users"
> > > (https://www.spinics.net/lists/kernel/msg5811817.html).
> >
> > I can prepare a branch that fs can pull but aren't all the prerequisites
> > already in the master branch from the last cycle?
...
> There is still the logic inside "include/linux/workqueue.h", in
> queue_delayed_work() / mod_delayed_work() / queue_work().
> Just the pr_warn_once() and the workqueue redirection.

These are not prerequisites, right? In fact, we should add the warnings only
after most of the tree have already been converted.

> These changes are introduced by 2 different patches, based on when the
> two new wq(s) are replaced inside the code.
> 
> There are also changes inside  __alloc_workqueue(), always in this
> series (when WQ_PERCPU is used), because they are the "general" (core)
> changes.
> 
> If I remember correctly we decided to keep the prerequisites without
> any more "logic".
> As long as this series is merged before or anyhow in the same rc, I
> think there are no problems; right?

I'm having a bit of difficult time understanding the logic behind how the
patches are laid out. This, while a bit tedious, shouldn't be that
complicated:

- Add all the new things to workqueue[.hc] so that the users can be
  converted in whatever unit each subsystem wants. Note that this shouldn't
  add any warnings or cause behavior changes. Just introduce new interface
  and convert the subsystems clarifying that it's a noop change.

- Once of the initial conversion pass is done and merged. Add warnings and
  other mechanisms to get the stragglers and prevent further addition of old
  interface. We can do this right after a merge window as a fix patch so
  that we don't have to straddle multiple releases.

- Go subsystem by subsystem and make the functional change you want to make
  (here, converting from percpu to dfl). This can proceed without being
  coupled with anything else.

- After a cycle, drop the old interface.

What not to do:

- Don't make workqueue changes combined with a lot of changes to other
  subsystems. Workqueue changes should come and after those, not together
  with.

Thanks.

-- 
tejun

  reply	other threads:[~2025-08-21 20:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-15  9:45 Marco Crivellari
2025-08-15  9:45 ` [PATCH 1/4] Workqueue: replace use of system_wq with system_percpu_wq Marco Crivellari
2025-08-15  9:45 ` [PATCH 2/4] Workqueue: replace use of system_unbound_wq with system_dfl_wq Marco Crivellari
2025-08-15  9:45 ` [PATCH 3/4] Workqueue: WQ_PERCPU added to all the remaining users Marco Crivellari
2025-08-15  9:45 ` [PATCH 4/4] [Doc] Workqueue: WQ_UNBOUND doc upgraded Marco Crivellari
2025-08-15 18:04 ` [PATCH 0/4] Workqueue: replace system wq and change alloc_workqueue callers Tejun Heo
2025-08-19  8:41   ` Marco Crivellari
2025-08-20 23:22     ` Tejun Heo
2025-08-21  7:44       ` Marco Crivellari
2025-08-19 12:28   ` Marco Crivellari
2025-08-20 23:19     ` Tejun Heo
2025-08-21  7:40       ` Marco Crivellari
2025-08-21 20:29         ` Tejun Heo [this message]
2025-08-25 10:38           ` Marco Crivellari

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aKeBr3eBfh0wr_fH@slm.duckdns.org \
    --to=tj@kernel.org \
    --cc=bigeasy@linutronix.de \
    --cc=frederic@kernel.org \
    --cc=jiangshanlai@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marco.crivellari@suse.com \
    --cc=mhocko@suse.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®