mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: linux-kernel@vger.kernel.org, linux-tip-commits@vger.kernel.org,
	x86 <x86@kernel.org>
Subject: Re: [tip: core/rcu] rcu: Enable tick for nohz_full CPUs slow to provide expedited QS
Date: Sat, 25 Jan 2020 11:48:46 -0800	[thread overview]
Message-ID: <20200125194846.GF2935@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <20200125175442.GA4369@zn.tnic>

On Sat, Jan 25, 2020 at 06:54:42PM +0100, Borislav Petkov wrote:
> On Sat, Jan 25, 2020 at 08:10:50AM -0800, Paul E. McKenney wrote:
> > How big?  (Seriously, given that the fix may depend on the number of CPUs.)
> 
> [    7.660017] smp: Brought up 2 nodes, 256 CPUs
> 
> > So the problem appears to be that some of the boot-time processing
> > is looping in the kernel, which is preventing the grace period from
> > completing.  One could argue that such code should be fixed, but on the
> > other hand, boot time is a bit special.  Later in -rcu's dev branch,
> > there are commits that forgive this boot-time misbehavior, but this is
> > a bit late in process to dump all of those commits into -tip.
> 
> Aha.
> 
> > The RT guys might need the warning, and it was them that I was thinking
> > of when adding it. 
> 
> But "boot time is a bit special". Or do they care about deadlines during
> boot too?

Maybe, but not that I know of.  If they do, this would be an excellent
time for them to let me know!

My guess is "no" because the real-time application would not yet be
running during boot.  On the other hand, if this issue is due not so much
to boot, but to (say) expensive filesystem operations on large systems,
that might be a different story.

Except that I would have hard questions to ask of someone doing expensive
filesystem operations while their deep-sub-millisecond real-time
application was running.  So even then, I doubt that they would care.

Again, if I am wrong about this, this would be an excellent time for
them to let me know.

> > But let's see what works for mainline first.  And
> > since your box was booting fine without the warning before, I bet that
> > it boots just fine with that warning removed.
> 
> Yes, it does.

Woo-hoo!!!

> > So could you please try out the (untested) patch below?
> 
> Warning's gone.

Very good.  I will get it property prepared and tested, then send it
along to Ingo.

> > If that works, I will re-introduce the warning with proper protection
> > for the merge window following this coming one.
> 
> My big box is at your service if you need stuff tested later.

Thank you in advance!  I just might take you up on that!

In the meantime, one question...  Are you testing for realtime suitability
on your big box?  If so, to what extent?

> Thx Paul.
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

Aside from habitually failing to trim emails, which of these was I
violating?  ;-)

							Thanx, Paul

  reply	other threads:[~2020-01-25 19:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-25 10:42 tip-bot2 for Paul E. McKenney
2020-01-25 13:14 ` Borislav Petkov
2020-01-25 16:10   ` Paul E. McKenney
2020-01-25 17:54     ` Borislav Petkov
2020-01-25 19:48       ` Paul E. McKenney [this message]
2020-01-25 20:08         ` Paul E. McKenney
2020-01-25 20:23           ` Borislav Petkov
2020-01-25 20:19         ` Borislav Petkov
2020-01-26  1:43         ` Paul E. McKenney
2020-01-26 11:25           ` Borislav Petkov
2020-01-26 15:28             ` Paul E. McKenney
2020-01-26 17:19               ` Borislav Petkov

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=20200125194846.GF2935@paulmck-ThinkPad-P72 \
    --to=paulmck@kernel.org \
    --cc=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=x86@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 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®