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 10. 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++; into 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 star. 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. Linus - 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/