From: Peter Zijlstra <peterz@infradead.org>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Boqun Feng <boqun.feng@gmail.com>,
Joel Fernandes <joel@joelfernandes.org>,
Josh Triplett <josh@joshtriplett.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Neeraj Upadhyay <neeraj.upadhyay@amd.com>,
"Paul E . McKenney" <paulmck@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Uladzislau Rezki <urezki@gmail.com>, rcu <rcu@vger.kernel.org>,
Zqiang <qiang.zhang1211@gmail.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Sebastian Siewior <bigeasy@linutronix.de>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 4/4] Revert "kernel/sched: Modify initial boot task idle setup"
Date: Fri, 20 Oct 2023 10:25:31 +0200 [thread overview]
Message-ID: <20231020082531.GS33217@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20231019233543.1243121-5-frederic@kernel.org>
On Fri, Oct 20, 2023 at 01:35:43AM +0200, Frederic Weisbecker wrote:
> Now that rcutiny can deal with early boot PF_IDLE setting, revert
> commit cff9b2332ab762b7e0586c793c431a8f2ea4db04.
>
> This fixes several subtle issues introduced on RCU-tasks(-trace):
>
> 1) RCU-tasks stalls when:
>
> 1.1 Grace period is started before init/0 had a chance to set PF_IDLE,
> keeping it stuck in the holdout list until idle ever schedules.
>
> 1.2 Grace period is started when some possible CPUs have never been
> online, keeping their idle tasks stuck in the holdout list until
> the CPU ever boots up.
>
> 1.3 Similar to 1.1 but with secondary CPUs: Grace period is started
> concurrently with secondary CPU booting, putting its idle task in
> the holdout list because PF_IDLE isn't yet observed on it. It
> stays then stuck in the holdout list until that CPU ever
> schedules. The effect is mitigated here by all the smpboot
> kthreads and the hotplug AP thread that must run to bring the
> CPU up.
>
> 2) Spurious warning on RCU task trace that assumes offline CPU's idle
> task is always PF_IDLE.
>
> More issues have been found in RCU-tasks related to PF_IDLE which should
> be fixed with later changes as those are not regressions:
>
> 3) The RCU-Tasks semantics consider the idle loop as a quiescent state,
> however:
>
> 3.1 The boot code preceding the idle entry is included in this
> quiescent state. Especially after the completion of kthreadd_done
> after which init/1 can launch userspace concurrently. The window
> is tiny before PF_IDLE is set but it exists.
>
> 3.2 Similarly, the boot code preceding the idle entry on secondary
> CPUs is wrongly accounted as RCU tasks quiescent state.
>
Urgh... so the plan is to fix RCU-tasks for all of the above to not rely
on PF_IDLE ? Because I rather like the more strict PF_IDLE and
subsequently don't much like this revert.
next prev parent reply other threads:[~2023-10-20 8:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-19 23:35 [PATCH 0/4] rcu: Fix PF_IDLE related issues, part. 1 Frederic Weisbecker
2023-10-19 23:35 ` [PATCH 1/4] softirq: Rename __raise_softirq_irqoff() to raise_softirq_no_wake() Frederic Weisbecker
2023-10-19 23:35 ` [PATCH 2/4] softirq: Introduce raise_ksoftirqd_irqoff() Frederic Weisbecker
2023-10-19 23:35 ` [PATCH 3/4] rcu: Make tiny RCU use ksoftirqd to trigger a QS from idle Frederic Weisbecker
2023-10-20 0:49 ` Paul E. McKenney
2023-10-19 23:35 ` [PATCH 4/4] Revert "kernel/sched: Modify initial boot task idle setup" Frederic Weisbecker
2023-10-20 8:25 ` Peter Zijlstra [this message]
2023-10-20 12:31 ` Frederic Weisbecker
2023-10-20 13:48 ` Peter Zijlstra
2023-10-20 15:05 ` Paul E. McKenney
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=20231020082531.GS33217@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=Liam.Howlett@oracle.com \
--cc=bigeasy@linutronix.de \
--cc=boqun.feng@gmail.com \
--cc=frederic@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=neeraj.upadhyay@amd.com \
--cc=paulmck@kernel.org \
--cc=qiang.zhang1211@gmail.com \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=urezki@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.