[PATCH] ppc32: add CONFIG_HZ

[PATCH] ppc32: add CONFIG_HZ

[Kumar Gala]

While ppc32 has the CONFIG_HZ Kconfig option, it wasnt actually being
used. Connect it up and set all platforms to 250Hz.  This pretty much
mimics the ppc64 patch from Anton Blanchard.

Signed-off-by: Kumar Gala <kumar.gala@freescale.com>

---
commit a7d81273171d49ac130f303eb63903298b4aeefb
tree a36b7872c98068519b9d85aa16e5f3f0b1668183
parent d90fa018552f3c3515ec46beadc0f0ff64c54547
author Kumar K. Gala <kumar.gala@freescale.com> Fri, 26 Aug 2005 14:14:40 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Fri, 26 Aug 2005 14:14:40 -0500

 include/asm-ppc/param.h |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/include/asm-ppc/param.h b/include/asm-ppc/param.h
--- a/include/asm-ppc/param.h
+++ b/include/asm-ppc/param.h
@@ -1,8 +1,10 @@
 #ifndef _ASM_PPC_PARAM_H
 #define _ASM_PPC_PARAM_H
 
+#include <linux/config.h>
+
 #ifdef __KERNEL__
-#define HZ		1000		/* internal timer frequency */
+#define HZ		CONFIG_HZ	/* internal timer frequency */
 #define USER_HZ		100		/* for user interfaces in "ticks" */
 #define CLOCKS_PER_SEC	(USER_HZ)	/* frequency at which times() counts */
 #endif /* __KERNEL__ */

Re: [PATCH] ppc32: add CONFIG_HZ

[Dan Malek]

On Aug 26, 2005, at 3:15 PM, Kumar Gala wrote:

> While ppc32 has the CONFIG_HZ Kconfig option, it wasnt actually being
> used. Connect it up and set all platforms to 250Hz.  This pretty much
> mimics the ppc64 patch from Anton Blanchard.

Why do we keep cranking up this clock frequency?  Do we really need
it running that fast?  Is it time for someone with RTOS experience to
implement a real scheduled clock queue in Linux instead of just
wasting interrupts decrementing a counter waiting for the next
event to expire?  :-)  If the user "ticks" are still 100 Hz, don't we 
need
something that is an integer multiple of that for at least an attempt
at getting it close to what a user would request?

Thanks.

	-- Dan

Re: [PATCH] ppc32: add CONFIG_HZ

[Tom Rini]

On Fri, Aug 26, 2005 at 04:13:04PM -0400, Dan Malek wrote:
> 
> On Aug 26, 2005, at 3:15 PM, Kumar Gala wrote:
> 
> >While ppc32 has the CONFIG_HZ Kconfig option, it wasnt actually being
> >used. Connect it up and set all platforms to 250Hz.  This pretty much
> >mimics the ppc64 patch from Anton Blanchard.
> 
> Why do we keep cranking up this clock frequency?  Do we really need
> it running that fast?  Is it time for someone with RTOS experience to
> implement a real scheduled clock queue in Linux instead of just
> wasting interrupts decrementing a counter waiting for the next
> event to expire?  :-)  If the user "ticks" are still 100 Hz, don't we 
> need
> something that is an integer multiple of that for at least an attempt
> at getting it close to what a user would request?

So 250 is supposed to be the best choice of power vs latency and such.
But hey, there's nothing stopping us from setting all of the embedded
configs back down to 100 :)

-- 
Tom Rini
http://gate.crashing.org/~trini/

RE: [PATCH] ppc32: add CONFIG_HZ

[Rune Torgersen]

On Friday, August 26, 2005 16:32 Tom Rini wrote:
> So 250 is supposed to be the best choice of power vs latency and such.
> But hey, there's nothing stopping us from setting all of the embedded
> configs back down to 100 :)

I thought the default value for HZ in 2.6 was 1000?
At least this is what it is set at for the 82xx (and bigger embedded)
boards=20

Re: [PATCH] ppc32: add CONFIG_HZ

[Dan Malek]

On Aug 26, 2005, at 5:31 PM, Tom Rini wrote:

> So 250 is supposed to be the best choice of power vs latency and such.

Hahahaha!  Now I've hear it all.  I can go home now.
A proper event driven timer would be the best choice ......

Thanks.


	-- Dan

Re: [PATCH] ppc32: add CONFIG_HZ

[Dan Malek]

On Aug 26, 2005, at 6:48 PM, Rune Torgersen wrote:

> I thought the default value for HZ in 2.6 was 1000?
> At least this is what it is set at for the 82xx (and bigger embedded)
> boards

Oh geeze, no wonder we can't get any performance
out of 2.6 on these boards.   Between that and the TLB
thrashing going on there's nothing left for the applications :-)


	-- Dan

Re: [PATCH] ppc32: add CONFIG_HZ

[Tom Rini]

On Fri, Aug 26, 2005 at 05:48:53PM -0500, Rune Torgersen wrote:
> On Friday, August 26, 2005 16:32 Tom Rini wrote:
> > So 250 is supposed to be the best choice of power vs latency and such.
> > But hey, there's nothing stopping us from setting all of the embedded
> > configs back down to 100 :)
> 
> I thought the default value for HZ in 2.6 was 1000?

Yes, it was.  With 2.6.13 and on i386 (and other arches that actually
make use of the question) it can be any of 100, 250 or 1000.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: [PATCH] ppc32: add CONFIG_HZ

[Dan Malek]

On Aug 26, 2005, at 6:55 PM, Tom Rini wrote:

> Yes, it was.  With 2.6.13 and on i386 (and other arches that actually
> make use of the question) it can be any of 100, 250 or 1000.

Well, 250 just seems wrong as I mentioned in a previous message.
It will function, but an application is going to see lots of clock 
jitter
unless you work in multiples of 100.  My choices would be 100, 200,
500, or 1000.

Thanks.

	-- Dan

Re: [PATCH] ppc32: add CONFIG_HZ

[Tom Rini]

On Fri, Aug 26, 2005 at 07:07:01PM -0400, Dan Malek wrote:
> 
> On Aug 26, 2005, at 6:55 PM, Tom Rini wrote:
> 
> >Yes, it was.  With 2.6.13 and on i386 (and other arches that actually
> >make use of the question) it can be any of 100, 250 or 1000.
> 
> Well, 250 just seems wrong as I mentioned in a previous message.
> It will function, but an application is going to see lots of clock 
> jitter
> unless you work in multiples of 100.  My choices would be 100, 200,
> 500, or 1000.

That's an arguement for lkml.  But as I recall things, there shouldn't
be jitter, probably, with non multiples of 100.  There was some
discussion, and a fair bit of flaming about all of this on lkml.  I
think with some sort of numbers Linus might buy another choice added to
the list, but refuses anything "in theory" (this stems in part from the
must be 1000 crowd not being happy about 250 as the default).

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: [PATCH] ppc32: add CONFIG_HZ

[Grant Likely]

On Fri, Aug 26, 2005 at 07:07:01PM -0400, Dan Malek wrote:
> 
> On Aug 26, 2005, at 6:55 PM, Tom Rini wrote:
> 
> >Yes, it was.  With 2.6.13 and on i386 (and other arches that actually
> >make use of the question) it can be any of 100, 250 or 1000.
> 
> Well, 250 just seems wrong as I mentioned in a previous message.
> It will function, but an application is going to see lots of clock 
> jitter
> unless you work in multiples of 100.  My choices would be 100, 200,
> 500, or 1000.
What's the reason for clock jitter?  Is it because most timeouts are set
to multiples of 100, or some other reason?

Thanks,
g.

Re: [PATCH] ppc32: add CONFIG_HZ

[Dan Malek]

On Aug 27, 2005, at 1:04 AM, Grant Likely wrote:

> What's the reason for clock jitter?  Is it because most timeouts are 
> set
> to multiples of 100, or some other reason?

Yes, the application interfaces are all defined as 100 Hz (10 mSec).
If the POSIX timer implementation is done properly, it should be
possible to determine the timer parameters to eliminate this, but
I doubt any applications do this.  They all assume 10 mSec :-)


	-- Dan

Re: [PATCH] ppc32: add CONFIG_HZ

[Paul Mackerras]

Dan Malek writes:

> Yes, the application interfaces are all defined as 100 Hz (10 mSec).
> If the POSIX timer implementation is done properly, it should be
> possible to determine the timer parameters to eliminate this, but
> I doubt any applications do this.  They all assume 10 mSec :-)

There are in fact only a few interfaces that work in terms of "clock
ticks", which are 10ms as far as userspace is concerned.  I can think
of times() and that's about it.  There are also the si_utime and
si_stime fields of the siginfo_t that comes along with a SIGCHLD.  All
of those are about reporting CPU time used, not about specifying
timeouts.

All of the interfaces that specify timeouts or control timers use
struct timeval (seconds + microseconds) or struct timespec (seconds +
nanoseconds), or else use milliseconds (e.g. poll()).

Paul.

Re: [PATCH] ppc32: add CONFIG_HZ

[Segher Boessenkool]

>> While ppc32 has the CONFIG_HZ Kconfig option, it wasnt actually being
>> used. Connect it up and set all platforms to 250Hz.  This pretty much
>> mimics the ppc64 patch from Anton Blanchard.
>
> Why do we keep cranking up this clock frequency?  Do we really need
> it running that fast?  Is it time for someone with RTOS experience to
> implement a real scheduled clock queue in Linux instead of just
> wasting interrupts decrementing a counter waiting for the next
> event to expire?  :-)

Sure.  And some people are actually working on that.  But
on common x86 hardware, it seems to be a really really hard
thing to do.  Would be a lot easier in PowerPC of course...


Segher

Re: [PATCH] ppc32: add CONFIG_HZ

[Marcelo Tosatti]

On Fri, Aug 26, 2005 at 02:31:44PM -0700, Tom Rini wrote:
> On Fri, Aug 26, 2005 at 04:13:04PM -0400, Dan Malek wrote:
> > 
> > On Aug 26, 2005, at 3:15 PM, Kumar Gala wrote:
> > 
> > >While ppc32 has the CONFIG_HZ Kconfig option, it wasnt actually being
> > >used. Connect it up and set all platforms to 250Hz.  This pretty much
> > >mimics the ppc64 patch from Anton Blanchard.
> > 
> > Why do we keep cranking up this clock frequency?  Do we really need
> > it running that fast?  Is it time for someone with RTOS experience to
> > implement a real scheduled clock queue in Linux instead of just
> > wasting interrupts decrementing a counter waiting for the next
> > event to expire?  :-)  If the user "ticks" are still 100 Hz, don't we 
> > need
> > something that is an integer multiple of that for at least an attempt
> > at getting it close to what a user would request?
> 
> So 250 is supposed to be the best choice of power vs latency and such.
> But hey, there's nothing stopping us from setting all of the embedded
> configs back down to 100 :)

Yep. 

Kumar, can you please change your patch to make CONFIG_8xx use 100Hz?

There was a significant performance increase from doing that (vs 1000Hz)
on a 48Mhz 8xx with small cache.

Re: [PATCH] ppc32: add CONFIG_HZ

[Kumar Gala]

> Yep.
>
> Kumar, can you please change your patch to make CONFIG_8xx use 100Hz?
>
> There was a significant performance increase from doing that (vs  
> 1000Hz)
> on a 48Mhz 8xx with small cache.
>

I'd be happy to, but I'm not 100% sure how to get the Kconfig system  
to do that on a sub-arch case.  Right now the default is 250Hz based  
on the global kernel/Kconfig.hz.  If we want we can effectively  
replicate the Kconfig.hz functionality into arch/ppc/Kconfig which  
would give us more flexibility but I'd prefer not to do that.

Idea's on how to solve this are welcome.

- kumar

Re: [PATCH] ppc32: add CONFIG_HZ

[Dan Malek]

On Sep 8, 2005, at 10:11 AM, Kumar Gala wrote:

> Idea's on how to solve this are welcome.

Just create the appropriate defconfigs with this clock
frequency and check them in.

Thanks.

	-- Dan