Message-ID: <X/yzrJw4UbQsK3KB@hirez.programming.kicks-ass.net>
Date:   Mon, 11 Jan 2021 21:23:08 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Valentin Schneider <valentin.schneider@....com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        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 Mon, Jan 11, 2021 at 07:21:06PM +0000, Valentin Schneider wrote:
> On 11/01/21 18:16, Peter Zijlstra wrote:
> > Sadly it appears like io_uring() uses kthread_create_on_cpu() without
> > then having any hotplug crud on, so that needs additinoal frobbing.
> >
> 
> I noticed that as well sometime ago, and I believed then (still do) this
> usage is broken. I don't think usage of kthread_create_on_cpu() outside
> of smpboot makes sense, because without any hotplug step to park the
> thread, its affinity can end up being reset after its dedicated CPU gets
> offlined.
> 
> I'm clueless about io_uring, but if it *actually* has a good reason to
> use some pcpu kthreads (it seems it doesn't have to be on all CPUs?),
> then it needs to register some hotplug step to park them / do something
> sensible on hotplug.

+Jens, could you perhaps elucidate us as to what io_uring wants from
that kthread?

> > Also, init_task is PF_KTHREAD but doesn't have a struct kthread on.. and
> > I suppose bound workqueues don't go through this either.
> >
> > Let me rummage around a bit...
> >
> > This seems to not insta-explode... opinions?
> >
> 
> I like having a proper distinction between 'intended' and 'accidental'
> pcpu kthreads.
> 
> I'm less fond of the workqueue pcpu flag toggling, but it gets us what
> we want: allow those threads to run on !active CPUs during online, but
> move them away before !online during offline.
> 
> Before I get ahead of myself, do we *actually* require that first part
> for workqueue kthreads? I'm thinking (raise alarm) we could try another
> approach of making them pcpu kthreads that don't abide by the !active &&
> online rule.

There is code that really requires percpu workqueues to be percpu. Such
code will flush the percpu workqueue on hotplug and never hit the unbind
scenario.

Other code uses those same percpu workqueues and only uses it as a
performance enhancer, it likes things to stay local, but if not, meh..
And these users are what got us the weird ass semantics of workqueue.

Sadly workqueue itself can't tell them apart.

> > ---
> >  include/linux/kthread.h |  3 +++
> >  kernel/kthread.c        | 25 ++++++++++++++++++++++++-
> >  kernel/sched/core.c     |  2 +-
> >  kernel/sched/sched.h    |  4 ++--
> >  kernel/smpboot.c        |  1 +
> >  kernel/workqueue.c      | 12 +++++++++---
> >  6 files changed, 40 insertions(+), 7 deletions(-)
> >
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index 15d2562118d1..e71f9e44789e 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -7277,7 +7277,7 @@ static void balance_push(struct rq *rq)
> >        * Both the cpu-hotplug and stop task are in this case and are
> >        * required to complete the hotplug process.
> >        */
> > -	if (is_per_cpu_kthread(push_task) || is_migration_disabled(push_task)) {
> > +	if (rq->idle == push_task || is_per_cpu_kthread(push_task) || is_migration_disabled(push_task)) {
> 
> I take it the p->set_child_tid thing you were complaining about on IRC
> is what prevents us from having the idle task seen as a pcpu kthread?

Yes, to to_kthread() only tests PF_KTHREAD and then assumes
p->set_child_tid points to struct kthread, _however_ init_task has
PF_KTHREAD set, but a NULL ->set_child_tid.

This then means the idle thread for the boot CPU will malfunction with
to_kthread() and will certainly not have KTHREAD_IS_PER_CPU set. Per
construction (fork_idle()) none of the other idle threads will have that
cured either.

For fun and giggles, init (pid-1) will have PF_KTHREAD set for a while
as well, until we exec /sbin/init.

Anyway, idle will fail kthread_is_per_cpu(), and hence without the
above, we'll try and push the idle task away, which results in much
fail.

> > diff --git a/kernel/smpboot.c b/kernel/smpboot.c
> > index 2efe1e206167..b0abe575a524 100644
> > --- a/kernel/smpboot.c
> > +++ b/kernel/smpboot.c
> > @@ -188,6 +188,7 @@ __smpboot_create_thread(struct smp_hotplug_thread *ht, unsigned int cpu)
> >               kfree(td);
> >               return PTR_ERR(tsk);
> >       }
> > +	kthread_set_per_cpu(tsk, true);
> >       /*
> >        * Park the thread so that it could start right on the CPU
> >        * when it is available.
> > diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> > index 9880b6c0e272..824276e4fb2e 100644
> > --- a/kernel/workqueue.c
> > +++ b/kernel/workqueue.c
> > @@ -1861,6 +1861,8 @@ static void worker_attach_to_pool(struct worker *worker,
> >        */
> >       if (pool->flags & POOL_DISASSOCIATED)
> >               worker->flags |= WORKER_UNBOUND;
> > +	else
> > +		kthread_set_per_cpu(worker->task, true);
> >
> 
> I thought only pcpu pools would get the POOL_DISASSOCIATED flag on
> offline, but it seems unbound pools also get it at init time. Did I get
> that right?

That's how I read it too...

> Also, shouldn't this be done before the previous set_cpus_allowed_ptr()
> call (in the same function)? 

Don't see why; we need nr_cpus_allowed == 1, so best do it after, right?

> That is, if we patch
> __set_cpus_allowed_ptr() to also use kthread_is_per_cpu().

That seems wrong.

> >       list_add_tail(&worker->node, &pool->workers);
> >       worker->pool = pool;

Powered by blists - more mailing lists