[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAofZF5ZJ36vr_8exeMrnLXxD1u6aaTR3kp+oEztKQYe4f0__Q@mail.gmail.com>
Date: Tue, 6 May 2025 09:53:47 +0200
From: Marco Crivellari <marco.crivellari@...e.com>
To: Michal Hocko <mhocko@...e.com>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>, linux-kernel@...r.kernel.org,
Tejun Heo <tj@...nel.org>, Lai Jiangshan <jiangshanlai@...il.com>,
Thomas Gleixner <tglx@...utronix.de>, Frederic Weisbecker <frederic@...nel.org>
Subject: Re: [PATCH 0/4] Workqueue: rename system workqueue and add WQ_PERCPU
Hi Michal,
I will integrate the cover letter with more information
(also pointed out by Tejun, I noticed).
Thanks!
On Mon, May 5, 2025 at 11:25 AM Michal Hocko <mhocko@...e.com> wrote:
>
> On Mon 05-05-25 08:51:21, Sebastian Andrzej Siewior wrote:
> > On 2025-05-03 10:28:30 [+0200], Marco Crivellari wrote:
> > > Hi!
> > Hi,
> >
> > > This series is the follow up of the discussion from:
> > > "workqueue: Always use wq_select_unbound_cpu() for WORK_CPU_UNBOUND."
> > > https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/
> > >
> > > 1) [P 1-2] system workqueue rename:
> > >
> > > system_wq is a per-CPU workqueue, but his name is not clear.
> > > system_unbound_wq is to be used when locality is not required.
> > >
> > > system_wq renamed in system_percpu_wq, while system_unbound_wq
> > > became system_dfl_wq.
> > >
> > > 2) [P 3] Introduction of WQ_PERCPU.
> > >
> > > This patch adds a new WQ_PERCPU flag to explicitly request the legacy
> > > per-CPU behavior. WQ_UNBOUND will be removed once the migration is
> > > complete.
> > >
> > > Every alloc_workqueue() caller should use one among WQ_PERCPU or
> > > WQ_UNBOUND. This is actually enforced warning if both or none of them
> > > are present at the same time.
> > >
> > > 3) [P 4] alloc_workqueue() callee should pass explicitly WQ_PERCPU.
> > >
> > > This patch ensures that every caller that needs per-cpu workqueue
> > > will explicitly require it, using the WQ_PERCPU flag.
> >
> > Sounds like a plan.
> > I assume the huge patches were made with coccinelle?
>
> Yes, this makes a lot of sense. I think it is worth mentioning why do we
> want/need to go through this major refactoring. From my POV this will
> help cpu isolation in a long term because it reduces unpredictable
> interference from pcp workers.
> --
> Michal Hocko
> SUSE Labs
--
Marco Crivellari
L3 Support Engineer, Technology & Product
marco.crivellari@...e.com
Powered by blists - more mailing lists