All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: sched_rt_period_timer causing large latencies
Date: Thu, 5 Apr 2018 20:44:40 +1000	[thread overview]
Message-ID: <20180405204440.3d5aa162@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <20180405200859.19fceb95@roar.ozlabs.ibm.com>

On Thu, 5 Apr 2018 20:08:59 +1000
Nicholas Piggin <npiggin@gmail.com> wrote:

> On Thu, 05 Apr 2018 10:40:20 +0200
> Mike Galbraith <efault@gmx.de> wrote:
> 
> > On Thu, 2018-04-05 at 10:27 +0200, Peter Zijlstra wrote:  
> > > On Thu, Apr 05, 2018 at 09:11:38AM +1000, Nicholas Piggin wrote:    
> > > > Hi,
> > > > 
> > > > I'm seeing some pretty big latencies on a ~idle system when a CPU wakes
> > > > out of a nohz idle. Looks like it's due to the taking a lot of remote
> > > > locks and cache lines. irqoff trace:    
> > > 
> > > On RT I think we default RT_RUNTIME_SHARE to false, maybe we should do
> > > the same for mainline.    
> > 
> > Probably.  My very first enterprise encounter with the thing was it NOT
> > saving a box from it's not so clever driver due to that.  
> 
> Well I would think a simpler per-cpu limiter might actually stand a
> better chance of saving you there. Or even something attached to the
> softlockup watchdog.
> 
> I'm still getting a lot of locks coming from sched_rt_period_timer
> with RT_RUNTIME_SHARE false, it's just that it's now down to about
> NR_CPUS locks rather than 3*NR_CPUS.

Oh yeah, putting -1 into sched_rt_runtime_us looks like it fixes it,
I didn't look at Mike's patch close enough.

If the code stays, it would be nice to be able to default it off at
least.

Thanks,
Nick

  reply	other threads:[~2018-04-05 10:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-04 23:11 sched_rt_period_timer causing large latencies Nicholas Piggin
2018-04-05  6:46 ` Mike Galbraith
2018-04-05  7:44   ` Nicholas Piggin
2018-04-05  8:11     ` Mike Galbraith
2018-04-05  8:27 ` Peter Zijlstra
2018-04-05  8:40   ` Mike Galbraith
2018-04-05 10:08     ` Nicholas Piggin
2018-04-05 10:44       ` Nicholas Piggin [this message]
2018-04-06 16:23       ` Peter Zijlstra

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=20180405204440.3d5aa162@roar.ozlabs.ibm.com \
    --to=npiggin@gmail.com \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.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.