[PATCH] ppc32: add CONFIG_HZ

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 <redacted>

---
commit a7d81273171d49ac130f303eb63903298b4aeefb
tree a36b7872c98068519b9d85aa16e5f3f0b1668183
parent d90fa018552f3c3515ec46beadc0f0ff64c54547
author Kumar K. Gala [off-list ref] Fri, 26 Aug 2005 14:14:40 -0500
committer Kumar K. Gala [off-list ref] 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__ */

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

On Fri, Aug 26, 2005 at 04:13:04PM -0400, Dan Malek wrote:

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

quoted

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/

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

quoted

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

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:

quoted

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

quoted

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.

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

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