On Thu, 14 Jul 2005, Lee Revell wrote:
> I don't think this will fly because we take a big performance hit by
> calculating HZ at runtime.

I think it might be an acceptable solution for a distribution that really 
needed it, since it should be fairly simple. However, it's definitely not 
the right solution.

HOWEVER. I bet that somebody who really really cares (hint hint) could
easily make HZ be 1000, and then dynamically tweak the divisor at bootup
to be either 1000, 250, or 100, and then increment "jiffies" by 1, 4 or

My wild guess is that this is 20 lines of code, plus another 20 for 
"setup", so that you can choose between 100/250/1000 Hz with a kernel 
command line.

It wouldn't be "dynamic" at first - you'd just set it up at bootup, and 
set a "jiffies_increment" variable, and change the



        jiffies_64 += jiffies_increment;

and you'd be done. 

Really. I dare you guys. First one to send me a tested patch gets a gold 

Then, a year from now, people will realize how _easy_ it is to change the
jiffies_increment on the fly, and add a /sys/kernel/timer_frequency file, 
and then you can switch it around at run-time.

Trust me. When I say that the right thing to do is to just have a fixed 
(but high) HZ value, and just changing the timer rate, I'm -right-.

I'm always right. This time I'm just even more right than usual.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to