All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Christoph Lameter <cl@linux.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Alok Kataria <akataria@vmware.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>,
	the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"alan@lxorguk.ukuu.org.uk" <alan@lxorguk.ukuu.org.uk>,
	anton@samba.org
Subject: Re: [PATCH] x86: Reduce the default HZ value
Date: Thu, 7 May 2009 12:51:42 -0700	[thread overview]
Message-ID: <20090507195142.GH6693@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0905071350550.22107@qirst.com>

On Thu, May 07, 2009 at 01:51:58PM -0400, Christoph Lameter wrote:
> On Thu, 7 May 2009, Paul E. McKenney wrote:
> 
> > On Thu, May 07, 2009 at 01:20:29PM -0400, Christoph Lameter wrote:
> > > On Thu, 7 May 2009, Peter Zijlstra wrote:
> > >
> > > > Another user is RCU, the grace period is tick driven, growing these
> > > > ticks by a factor 50 or so might require some tinkering with forced
> > > > grace periods when we notice our batch queues getting too long.
> > >
> > > One could also schedule RCU via hrtimers with a large fuzz period?
> >
> > You could, but then you would still have a periodic interrupt introducing
> > jitter into your HPC workload.  The approach I suggested allows RCU to be
> > happy with no periodic interrupts on any CPU that has only one runnable
> > task that is a CPU-bound user-level task (in addition to the idle task,
> > of course).
> 
> Sounds good.
> 
> An HPC workload typically has minimal kernel interaction. RCU would
> only need to run once and then the system would be quiet.

Peter Z's post leads me to believe that there might be dragons in
this approach that I am blissfully unaware of.  However, here is what
would have to happen from an RCU perspective, in case it helps:

o	This new mode needs to imply CONFIG_NO_HZ.

o	When a given CPU is transitioning into tickless mode, invoke
	rcu_enter_nohz().  This already happens for dynticks-idle,
	this would be a dynticks-CPU-bound-usermode-task.
	Note that CONFIG_NO_HZ kernels already invokes rcu_enter_nohz()
	from tick_nohz_stop_sched_tick(), and many of the things in
	tick_nohz_stop_sched_tick() would need to be done in this case
	as well.

o	When a given CPU is transitioning out of tickless mode, invoke
	rcu_exit_nohz().  Again, this already happens for dynticks-idle.
	Note that CONFIG_NO_HZ kernels already invoke rcu_exit_nohz() 
	from tick_nohz_restart_sched_tick(), which does other stuff that
	would be required in your case as well.

o	When a given CPU in tickless mode transitions into the kernel
	via a system call or trap, invoke rcu_irq_enter().  Note that
	rcu_irq_enter() is already invoked on irq entry if CONFIG_NO_HZ.
	NMIs are also already handled via rcu_nmi_enter().

o	When a given CPU in tickless mode transitions out of the kernel
	from a system call or trap, invoke rcu_irq_exit().  Note that
	rcu_irq_exit() is already invoked on irq exit if CONFIG_NO_HZ.
	NMIs are also already handled via rcu_nmi_exit().

Then RCU would know that any CPU running a CPU-bound user-mode task
need not be consulted when working out when a grace period ends, since
user-mode code cannot contain kernel-mode RCU read-side critical sections.

							Thanx, Paul

  reply	other threads:[~2009-05-07 19:52 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-04 18:44 [PATCH] x86: Reduce the default HZ value Alok Kataria
2009-05-05 21:21 ` H. Peter Anvin
2009-05-05 21:44   ` Alan Cox
2009-05-05 22:09     ` Alok Kataria
2009-05-05 22:33       ` Alan Cox
2009-05-05 23:37         ` Alok Kataria
2009-05-07 14:09         ` Christoph Lameter
2009-05-07 15:12           ` Alan Cox
2009-05-05 21:57   ` Alok Kataria
2009-05-07 14:13     ` Christoph Lameter
2009-05-07 15:14       ` Alan Cox
2009-05-07 15:20         ` Christoph Lameter
2009-05-07 15:30         ` H. Peter Anvin
2009-05-07 15:40           ` Christoph Lameter
2009-05-07 16:55           ` Jeff Garzik
2009-05-07 17:09             ` Alan Cox
2009-05-07 17:55               ` Jeff Garzik
2009-05-07 19:51                 ` Alan Cox
2009-05-07 20:03                   ` Jeff Garzik
2009-05-07 20:30                     ` Alan Cox
2009-05-07 16:37         ` Alok Kataria
2009-05-07 17:07       ` Peter Zijlstra
2009-05-07 17:13         ` Peter Zijlstra
2009-05-07 17:18           ` Peter Zijlstra
2009-05-07 17:20             ` Christoph Lameter
2009-05-07 17:39               ` Peter Zijlstra
2009-05-07 17:40                 ` Christoph Lameter
2009-05-07 17:54               ` Paul E. McKenney
2009-05-07 17:51                 ` Christoph Lameter
2009-05-07 19:51                   ` Paul E. McKenney [this message]
2009-05-07 17:36             ` Paul E. McKenney
2009-05-07 17:38               ` Peter Zijlstra
2009-05-07 18:01                 ` Paul E. McKenney
2009-05-07 18:12                   ` Christoph Lameter
2009-05-07 19:06                     ` Paul E. McKenney
2009-05-07 19:53                     ` Alan Cox
2009-05-07 19:56                       ` Christoph Lameter
2009-05-07 20:24                         ` Alan Cox
2009-05-07 20:21                           ` Christoph Lameter
2009-05-08 10:32                   ` Peter Zijlstra
2009-05-08 12:50                     ` Paul E. McKenney
2009-05-08 14:16                       ` Christoph Lameter
2009-05-08 15:06                         ` Paul E. McKenney
2009-05-07 17:18           ` Christoph Lameter
2009-05-07 17:37             ` Peter Zijlstra
2009-05-07 17:34               ` Christoph Lameter
2009-05-07 17:55                 ` Peter Zijlstra
2009-05-07 17:55                   ` Christoph Lameter
2009-05-07 17:19         ` Christoph Lameter
2009-05-07 17:45           ` Peter Zijlstra
2009-05-07 17:50             ` Christoph Lameter
2009-05-07 19:17               ` Peter Zijlstra
2009-05-07 19:38                 ` Christoph Lameter
2009-05-07 21:01             ` H. Peter Anvin
2009-05-07 16:35     ` Chris Snook
2009-05-07 16:56       ` Alok Kataria
2009-05-07 20:29         ` Chris Snook
2009-05-07 20:34           ` Alan Cox
2009-05-07 22:16             ` Ravikiran G Thirumalai
2009-05-07 22:19             ` Alok Kataria
2009-05-08  9:31               ` Alan Cox
  -- strict thread matches above, loose matches on Subject: below --
2009-05-12 19:45 devzero
2009-05-13 23:30 ` Alok Kataria
2009-05-14 20:25 devzero
2009-05-14 20:29 ` Alan Cox

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=20090507195142.GH6693@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akataria@vmware.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=anton@samba.org \
    --cc=cl@linux.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --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 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.