From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Christoph Lameter <cl@linux.com>,
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>
Subject: Re: [PATCH] x86: Reduce the default HZ value
Date: Thu, 7 May 2009 10:36:09 -0700 [thread overview]
Message-ID: <20090507173608.GC6693@linux.vnet.ibm.com> (raw)
In-Reply-To: <1241716718.6311.1531.camel@laptop>
On Thu, May 07, 2009 at 07:18:38PM +0200, Peter Zijlstra wrote:
> On Thu, 2009-05-07 at 19:13 +0200, Peter Zijlstra wrote:
> > On Thu, 2009-05-07 at 19:09 +0200, Peter Zijlstra wrote:
> > > On Thu, 2009-05-07 at 10:13 -0400, Christoph Lameter wrote:
> > > > I think we need to reduce the general tick frequency to be as low as
> > > > possible. With high resolution timers the tick frequency is just the
> > > > frequency with which the timer interrupt disturbs a running application.
> > > >
> > > > Are there any benefits remaining from frequent timer interrupts? I would
> > > > think that 60 HZ would be sufficient.
> > > >
> > > > It would be good if the kernel would be truly tickless. Scheduler events
> > > > would be driven by the scheduling intervals and not the invokations of the
> > > > scheduler softirq.
> > >
> > > The only thing that's driven by the softirq is load-balancing, there's
> > > way more to the scheduler-tick than kicking that thing awake every so
> > > often.
> > >
> > > The problem is that running the scheduler of off hrtimers is too
> > > expensive. We have the code, we tried it, people complained.
> >
> > Therefore, decreasing the HZ value to say 50, we'd get a minimum
> > involuntary preemption granularity of 20ms, something on the high end of
> > barely usable.
>
> 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 approach would be to enter nohz mode when running a CPU-bound
application on a CPU that had nothing else (other than the idle task)
on its runqueue and for which rcu_needs_cpu() returns zero. In this
mode, RCU would need to be informed on each system call, perhaps with an
rcu_kernel_enter() and rcu_kernel_exit() that work like rcu_irq_enter()
and rcu_irq_exit() -- and that perhaps replace rcu_irq_enter() and
rcu_irq_exit().
Then RCU would ignore any CPU that was executing a CPU-bound application,
allowing the HZ to be dialed down as low as you like, or perhaps really
entering something like nohz mode.
Thanx, Paul
next prev parent reply other threads:[~2009-05-07 17:36 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
2009-05-07 17:36 ` Paul E. McKenney [this message]
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=20090507173608.GC6693@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akataria@vmware.com \
--cc=alan@lxorguk.ukuu.org.uk \
--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.