From: "Paul E. McKenney" <paulmck@kernel.org>
To: Valentin Schneider <vschneid@redhat.com>
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com,
peterz@infradead.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
bristot@redhat.com
Subject: Re: "Dying CPU not properly vacated" splat
Date: Wed, 6 Sep 2023 06:08:16 -0700 [thread overview]
Message-ID: <c06ea3f3-4f07-42fb-9ad1-a227e9534bb1@paulmck-laptop> (raw)
In-Reply-To: <xhsmhsfmfc7s5.mognet@vschneid.remote.csb>
On Tue, Aug 02, 2022 at 10:30:02AM +0100, Valentin Schneider wrote:
> On 05/07/22 10:23, Paul E. McKenney wrote:
> > The second of these occurred near shutdown, but the first was quite some
> > time before shutdown. In case that makes a difference.
> >
> > I have not seen this since.
> >
> > Any other diagnostics I should add?
> >
>
> Sorry, I let this get buried to the bottom of my inbox :(
>
> I've had another look at rcutorture.c but just like for
> rcu_torture_reader(), I don't see any obvious culprit (no
> kthread_set_per_cpu() usage)).
>
> One thing I think would help is a scheduling trace (say sched_switch,
> sched_wakeup and cpuhp*, combined with ftrace_dump_on_oops + panic_on_warn
> ?) - that should at least tell us if the issue is in the wakeup placement
> (if the task gets placed on a dying CPU *after* CPUHP_AP_ACTIVE), or in the
> balance_push() mechanism (the task was *already* on the CPU when it started
> dying and never moved away).
>
> Neither make sense to me, but it has to be somewhere in there...
And given that it has been more than a year since I have seen this,
I am considering it to be fixed, whether purposefully or accidentally.
Thanx, Paul
prev parent reply other threads:[~2023-09-06 13:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-21 19:38 "Dying CPU not properly vacated" splat Paul E. McKenney
2022-04-25 16:15 ` Valentin Schneider
2022-04-25 17:33 ` Paul E. McKenney
2022-04-25 21:59 ` Valentin Schneider
2022-04-26 0:03 ` Paul E. McKenney
2022-04-26 14:48 ` Valentin Schneider
2022-04-26 16:24 ` Paul E. McKenney
2022-06-22 19:58 ` Paul E. McKenney
2022-07-05 7:45 ` Valentin Schneider
2022-07-05 17:23 ` Paul E. McKenney
2022-08-02 9:30 ` Valentin Schneider
2023-09-06 13:08 ` Paul E. McKenney [this message]
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=c06ea3f3-4f07-42fb-9ad1-a227e9534bb1@paulmck-laptop \
--to=paulmck@kernel.org \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.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 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.