From: Alok Kataria <akataria@vmware.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: 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: Tue, 05 May 2009 14:57:05 -0700 [thread overview]
Message-ID: <1241560625.8665.17.camel@alok-dev1> (raw)
In-Reply-To: <4A00ADDE.9000908@zytor.com>
On Tue, 2009-05-05 at 14:21 -0700, H. Peter Anvin wrote:
> Alok Kataria wrote:
> > Hi,
> >
> > Given that there were no major objections that came up regarding
> > reducing the HZ value in http://lkml.org/lkml/2009/4/27/499.
> >
> > Below is the patch which actually reduces it, please consider for tip.
> >
>
> What is the benefit of this?
I did some experiments on linux 2.6.29 guests running on VMware and
noticed that the number of timer interrupts could have some slowdown on
the total throughput on the system.
A simple tight loop experiment showed that with HZ=1000 we took about
264sec to complete the loop and that same loop took about 255sec with
HZ=100.
You can find more information here http://lkml.org/lkml/2009/4/28/401
And with HRT i don't see any downsides in terms of increased latencies
for device timer's or anything of that sought.
>
> I can see at least one immediate downside: some timeout values in the
> kernel are still maintained in units of HZ (like poll, I believe), and
> so with a lower HZ value we'll have higher roundoff errors.
If that at all is such a big problem shouldn't we think about moving to
using schedule_hrtimeout for such cases rather than relying on jiffy
based timeouts.
The hrtimer explanation over here http://www.tglx.de/hrtimers.html
also talks about where these HZ (timer wheel) based timeouts be used and
shouldn't really be dependent on accurate timing.
Also the default HZ value was 250 before this commit
commit 5cb04df8d3f03e37a19f2502591a84156be71772
x86: defconfig updates
And it was 250 for a very long time before that too. The commit log
doesn't explain why the value was bumped up either.
Thanks,
Alok
next prev parent reply other threads:[~2009-05-05 21:57 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 [this message]
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
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=1241560625.8665.17.camel@alok-dev1 \
--to=akataria@vmware.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox