From: "Paul E. McKenney" <paulmck@kernel.org>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: NOHZ tick-stop error: Non-RCU local softirq work is pending
Date: Thu, 10 Dec 2020 19:24:25 -0800 [thread overview]
Message-ID: <20201211032425.GC2657@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <20201211014031.GB580714@lothringen>
[-- Attachment #1: Type: text/plain, Size: 2050 bytes --]
On Fri, Dec 11, 2020 at 02:40:31AM +0100, Frederic Weisbecker wrote:
> On Thu, Dec 10, 2020 at 04:46:38PM -0800, Paul E. McKenney wrote:
> > > diff --git a/kernel/softirq.c b/kernel/softirq.c
> > > index 09229ad82209..7d558cb7a037 100644
> > > --- a/kernel/softirq.c
> > > +++ b/kernel/softirq.c
> > > @@ -650,7 +650,9 @@ static void run_ksoftirqd(unsigned int cpu)
> > > * We can safely run softirq on inline stack, as we are not deep
> > > * in the task stack here.
> > > */
> > > - __do_softirq();
> > > + do {
> > > + __do_softirq();
> > > + } while (kthread_should_park() && local_softirq_pending());
> > > local_irq_enable();
> > > cond_resched();
> > > return;
> >
> > Huh. I guess that self-propagating timers, RCU callbacks, and the
> > like are non-problems because they cannot retrigger while interrupts
> > are disabled? But can these things reappear just after the
> > local_irq_enable()?
>
> Exactly, unless those things have been disabled in CPU hotplug callbacks
> before smpboot_park_threads() (and we are not too deep in CPU hotplug at that
> stage, cpu_online() is still true), they should be able to raise again
> the softirqs. Yeah I'm pretty sure the above won't be enough.
>
> > In the case of RCU, softirq would need to run on this CPU, which it won't,
> > so we are good in that case. (Any stranded callbacks will be requeued
> > onto some other CPU later in the CPU-hotplug offline processing.)
>
> Ah that's good, so at least we shouldn't worry about pending RCU softirqs
> after ksoftirqd has parked. But I also see at least SCHED_SOFTIRQ and
> TIMER_SOFTIRQ in your list.
>
> Perhaps we should have some flush_softirq() somewhere late in cpu hotplug,
> assuming this is actually necessary and none of these will requeue themselves...
Indeed, let's see if we have a problem before we worry too much about
fixing it. ;-)
I still get the "NOHZ tick-stop error", but more than three times less
often, so definite improvement. One of the console.log file is attached.
Thanx, Paul
[-- Attachment #2: console1.log.gz --]
[-- Type: application/gzip, Size: 804216 bytes --]
prev parent reply other threads:[~2020-12-11 3:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-18 17:52 NOHZ tick-stop error: Non-RCU local softirq work is pending Paul E. McKenney
2020-11-18 17:54 ` Paul E. McKenney
2020-11-18 20:03 ` Paul E. McKenney
2020-12-10 13:04 ` Frederic Weisbecker
2020-12-10 14:56 ` Frederic Weisbecker
2020-12-10 21:17 ` Paul E. McKenney
2020-12-11 0:15 ` Frederic Weisbecker
2020-12-11 0:46 ` Paul E. McKenney
2020-12-11 1:40 ` Frederic Weisbecker
2020-12-11 3:24 ` 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=20201211032425.GC2657@paulmck-ThinkPad-P72 \
--to=paulmck@kernel.org \
--cc=frederic@kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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.