Skip to contentSkip to conversation

Confused about CLOCK_TICK_RATE

DISCUSSION Timur Tabi 3 participants 3 messages Mar 12, 2009 – Mar 19, 2009

lore
Share & tools
lore

Timur Tabi

author
#0 lore raw

Can someone explain CLOCK_TICK_RATE to me? It's defined in arch/powerpc/include/asm/timex.h as such:

#define CLOCK_TICK_RATE 1024000 /* Underlying HZ */

Every architecture defines this, but some use the better comment "Underlying frequency of the HZ timer".

My question is: why is this a constant? Shouldn't it be a variable, perhaps something that is based on tb_ticks_per_usec?

Signature · 2 lines
Timur Tabi
Linux kernel developer at Freescale
#1 lore raw
Quoted 10 lines · Timur Tabi

Can someone explain CLOCK_TICK_RATE to me? It's defined in arch/powerpc/include/asm/timex.h as such:

#define CLOCK_TICK_RATE 1024000 /* Underlying HZ */

Every architecture defines this, but some use the better comment "Underlying frequency of the HZ timer".

My question is: why is this a constant? Shouldn't it be a variable, perhaps something that is based on tb_ticks_per_usec?

Looks like legacy crud, originally meant to be the PIT input frequency, that isn't used for much on powerpc. It was probably chosen so as to make HZ == ACTHZ for the supported values of HZ.

-Scott

#2 lore raw
In reply to Timur Tabi
Quoted 10 lines · Timur Tabi

Can someone explain CLOCK_TICK_RATE to me? It's defined in arch/powerpc/include/asm/timex.h as such:

#define CLOCK_TICK_RATE 1024000 /* Underlying HZ */

Every architecture defines this, but some use the better comment "Underlying frequency of the HZ timer".

My question is: why is this a constant? Shouldn't it be a variable, perhaps something that is based on tb_ticks_per_usec?

It's used essentially for making small adjustments to ACTHZ and TICK_NSEC in include/linux/jiffies.h. The value was chosen so that ACTHZ == HZ and TICK_NSEC = 1e9 for all common HZ values, since we can't say at compile time what the decrementer frequency will be. I believe it's all pretty moot since we changed over to using the generic time framework anyway.

Paul.