All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Tim Pepper <lnxninja@linux.vnet.ibm.com>
Cc: Marcio Saito <marcio@cyclades.com>,
	Jiri Slaby <jirislaby@gmail.com>,
	John Stultz <johnstul@us.ibm.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	Ingo Molnar <mingo@redhat.com>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linuxppc-dev@lists.ozlabs.org,
	Avantika Mathur <mathur@linux.vnet.ibm.com>
Subject: Re: [RFC] [PATCH] allow low HZ values?
Date: Tue, 12 Oct 2010 09:30:12 +1100	[thread overview]
Message-ID: <1286836212.5220.19.camel@pasglop> (raw)
In-Reply-To: <20101011201121.GA953@tpepper-t61p.dolavim.us>

On Mon, 2010-10-11 at 13:11 -0700, Tim Pepper wrote:
> I'm not necessarily wanting to open up the age old question of "what is
> a good HZ", but we were doing some testing on timer tick overheads for
> HPC applications and this came up...

Note that this is also very useful when working on CPU prototypes
implemented in FPGAs and running at something like 12Mhz :-)

Cheers,
Ben.

> Below is a minimal hack at enabling lower HZ values.  The kernel builds
> and boots for me on x86_64 (simple laptop and kvm configs) and ppc64
> (misc. IBM System p) with each of the added HZ options.
> 
> There's explicit code checking HZ down to 12, but HZ<100 wasn't a config
> option.  We collected some data at 10, 12 and 25.  There'd been some
> question of whether 10 would even work or not but it looks fine in the
> relatively minimal testing we did.  We tried 12 since the code seemed
> to allow for it.  And 25 as a "safe" lower value.  The only difference
> observed under load (ie: no no idle HZ in play) was the expected timer
> tick happening less often.  There was definitely surprise that nothing
> else seemed to break anywhere, especially at 10.
> 
> Do people feel it is reasonable to have Kconfig bits to allow some lower
> HZ values?
> 
> If so, then there's the question of what breaks.  It's reasonable to
> think there are other going to be subtleties buried in code around
> assumptions on the likely range of HZ:
> 
> - I'm not sure that what I did in inet_timewait_sock.h and jiffies.h is
>   reasonable.
> - arch/x86/kernel/i8253.c throws a warning at line 43 (v2.6.36-rc7):
>       warning: large integer implicitly truncated to unsigned type
> - drivers/char/cyclades.c's cy_ioctl() warns:
>       drivers/char/cyclades.c:2761: warning: division by zero
> - drivers, drivers, drivers across all the arch's could use sanity checking
> 

WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Tim Pepper <lnxninja@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, Marcio Saito <marcio@cyclades.com>,
	Jiri Slaby <jirislaby@gmail.com>,
	Paul Mackerras <paulus@samba.org>,
	linuxppc-dev@lists.ozlabs.org, John Stultz <johnstul@us.ibm.com>,
	Avantika Mathur <mathur@linux.vnet.ibm.com>
Subject: Re: [RFC] [PATCH] allow low HZ values?
Date: Tue, 12 Oct 2010 09:30:12 +1100	[thread overview]
Message-ID: <1286836212.5220.19.camel@pasglop> (raw)
In-Reply-To: <20101011201121.GA953@tpepper-t61p.dolavim.us>

On Mon, 2010-10-11 at 13:11 -0700, Tim Pepper wrote:
> I'm not necessarily wanting to open up the age old question of "what is
> a good HZ", but we were doing some testing on timer tick overheads for
> HPC applications and this came up...

Note that this is also very useful when working on CPU prototypes
implemented in FPGAs and running at something like 12Mhz :-)

Cheers,
Ben.

> Below is a minimal hack at enabling lower HZ values.  The kernel builds
> and boots for me on x86_64 (simple laptop and kvm configs) and ppc64
> (misc. IBM System p) with each of the added HZ options.
> 
> There's explicit code checking HZ down to 12, but HZ<100 wasn't a config
> option.  We collected some data at 10, 12 and 25.  There'd been some
> question of whether 10 would even work or not but it looks fine in the
> relatively minimal testing we did.  We tried 12 since the code seemed
> to allow for it.  And 25 as a "safe" lower value.  The only difference
> observed under load (ie: no no idle HZ in play) was the expected timer
> tick happening less often.  There was definitely surprise that nothing
> else seemed to break anywhere, especially at 10.
> 
> Do people feel it is reasonable to have Kconfig bits to allow some lower
> HZ values?
> 
> If so, then there's the question of what breaks.  It's reasonable to
> think there are other going to be subtleties buried in code around
> assumptions on the likely range of HZ:
> 
> - I'm not sure that what I did in inet_timewait_sock.h and jiffies.h is
>   reasonable.
> - arch/x86/kernel/i8253.c throws a warning at line 43 (v2.6.36-rc7):
>       warning: large integer implicitly truncated to unsigned type
> - drivers/char/cyclades.c's cy_ioctl() warns:
>       drivers/char/cyclades.c:2761: warning: division by zero
> - drivers, drivers, drivers across all the arch's could use sanity checking
> 



  parent reply	other threads:[~2010-10-11 22:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-11 20:11 [RFC] [PATCH] allow low HZ values? Tim Pepper
2010-10-11 20:11 ` Tim Pepper
2010-10-11 20:32 ` Thomas Gleixner
2010-10-11 20:32   ` Thomas Gleixner
2010-10-11 21:11   ` Tim Pepper
2010-10-11 21:11     ` Tim Pepper
2010-10-12 14:31   ` Andi Kleen
2010-10-12 14:31     ` Andi Kleen
2010-10-12 16:56     ` Thomas Gleixner
2010-10-12 16:56       ` Thomas Gleixner
2010-10-11 22:30 ` Benjamin Herrenschmidt [this message]
2010-10-11 22:30   ` Benjamin Herrenschmidt
2010-10-11 22:33   ` Thomas Gleixner
2010-10-11 22:33     ` Thomas Gleixner
2010-10-11 22:47     ` H. Peter Anvin
2010-10-11 22:47       ` H. Peter Anvin

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=1286836212.5220.19.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=hpa@zytor.com \
    --cc=jirislaby@gmail.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lnxninja@linux.vnet.ibm.com \
    --cc=marcio@cyclades.com \
    --cc=mathur@linux.vnet.ibm.com \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.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.