From: Frederic Weisbecker <frederic@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: John Stultz <jstultz@google.com>,
LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
K Prateek Nayak <kprateek.nayak@amd.com>,
kernel-team@android.com, Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [RFC][PATCH] sched/core: Tweak wait_task_inactive() to force dequeue sched_delayed tasks
Date: Tue, 22 Apr 2025 11:55:31 +0200 [thread overview]
Message-ID: <aAdnk0PH6H5q7nGz@pavilion.home> (raw)
In-Reply-To: <20250422085628.GA14170@noisy.programming.kicks-ass.net>
Le Tue, Apr 22, 2025 at 10:56:28AM +0200, Peter Zijlstra a écrit :
> On Mon, Apr 21, 2025 at 09:43:45PM -0700, John Stultz wrote:
> > It was reported that in 6.12, smpboot_create_threads() was
> > taking much longer then in 6.6.
> >
> > I narrowed down the call path to:
> > smpboot_create_threads()
> > -> kthread_create_on_cpu()
> > -> kthread_bind()
> > -> __kthread_bind_mask()
> > ->wait_task_inactive()
> >
> > Where in wait_task_inactive() we were regularly hitting the
> > queued case, which sets a 1 tick timeout, which when called
> > multiple times in a row, accumulates quickly into a long
> > delay.
>
> Argh, this is all stupid :-(
>
> The whole __kthread_bind_*() thing is a bit weird, but fundamentally it
> tries to avoid a race vs current. Notably task_state::flags is only ever
> modified by current, except here.
>
> delayed_dequeue is fine, except wait_task_inactive() hasn't been
> told about it (I hate that function, murder death kill etc.).
>
> But more fundamentally, we've put so much crap into struct kthread and
> kthread() itself by now, why not also pass down the whole per-cpu-ness
> thing and simply do it there. Heck, Frederic already made it do affinity
> crud.
>
> On that, Frederic, *why* do you do that after started=1, that seems like
> a weird place, should this not be done before complete() ?, like next to
> sched_setscheduler_nocheck() or so?
You mean the call to kthread_affine_node() ? Because it is a default behaviour
that only happens if no call to kthread_bind() or kthread_affine_preferred()
has been issued before the first wake up to the kthread.
If kthread_affine_node() was called before everything by default instead
then we would get its unconditional overhead for all started kthreads. Plus
kthread_bind() and kthread_affine_preferred() would need to undo
kthread_affine_node().
Thanks.
--
Frederic Weisbecker
SUSE Labs
next prev parent reply other threads:[~2025-04-22 9:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-22 4:43 John Stultz
2025-04-22 6:43 ` K Prateek Nayak
2025-04-22 7:57 ` K Prateek Nayak
2025-04-22 8:56 ` Peter Zijlstra
2025-04-22 9:55 ` Frederic Weisbecker [this message]
2025-04-22 10:19 ` Peter Zijlstra
2025-04-23 21:41 ` John Stultz
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=aAdnk0PH6H5q7nGz@pavilion.home \
--to=frederic@kernel.org \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=fweisbec@gmail.com \
--cc=jstultz@google.com \
--cc=juri.lelli@redhat.com \
--cc=kernel-team@android.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
/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®