[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJhGHyDtku6PjLtkq7TGmcQnds5cakR6viki=bPoxxkdC0p-Tw@mail.gmail.com>
Date: Tue, 12 Jan 2021 23:38:12 +0800
From: Lai Jiangshan <jiangshanlai@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Valentin Schneider <valentin.schneider@....com>,
Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>, Qian Cai <cai@...hat.com>,
Vincent Donnefort <vincent.donnefort@....com>,
Dexuan Cui <decui@...rosoft.com>,
Lai Jiangshan <laijs@...ux.alibaba.com>,
Paul McKenney <paulmck@...nel.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
Steven Rostedt <rostedt@...dmis.org>,
Jens Axboe <axboe@...nel.dk>
Subject: Re: [PATCH -tip V3 0/8] workqueue: break affinity initiatively
On Tue, Jan 12, 2021 at 10:53 PM Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Tue, Jan 12, 2021 at 12:33:03PM +0800, Lai Jiangshan wrote:
> > > Well yes, but afaict the workqueue stuff hasn't been settled yet, and
> > > the rcutorture patch Paul did was just plain racy and who knows what
> > > other daft kthread users are out there. That and we're at -rc3.
> >
> > I just send the V4 patchset for the workqueue. Please take a look.
>
> Yes, I've seen it. But I think this approach is smaller and simpler.
>
> By distinguishing between geniuine per-cpu kthreads and kthreads that
> happen to have a single CPU affinity, things become much simpler and
> robust.
Again, fixing the problem of tasks running on dying cpu is easy.
(In other word, adjusting affinity correctly is easy, not matter adjusting
affinity initiatively like here or passively via new !KTHREAD_IS_PER_CPU)
For workqueue, Valentin Schneider patch can almost complete it, only
a small additional fix for percpu unbound workers needed.
And all four versions of my patchset can complete it.
But the hard problem is "how to suppress the warning of
online&!active in __set_cpus_allowed_ptr()" for late spawned
unbound workers during hotplug.
It is not handled completely until my fourth version patchset.
And your patchset ignores this theoretical case, I agree it is
Okay since no one has reported the warning in practice so far.
So something like CPUHP_AP_WORKQUEUE_UNBOUND_ONLINE is still needed
after your patchset merged.
Or you move the warning in __set_cpus_allowed_ptr() in deeper
places where the problem are really happen.
Powered by blists - more mailing lists