Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

[Linus Torvalds <torvalds@osdl.org>]

On Wed, 13 Jul 2005, Lee Revell wrote:
> 
> Interesting.  First they say it's impractical to reprogram the PIT, then
> they later imply that's exactly what Windows does, though for some
> reason they don't come out and say it.

I suspect that it is impractical to reprogram the PIT on a very fine
granularity.

Btw, if somebody really gets excited about all this, let me say (once 
again) what I think might be an acceptable situation.

First off, I'm _not_ a believer in "sub-HZ ticks". Quite the reverse. I 
think we should have HZ be some high value, but we would _slow_down_ the 
tick when not needed, and count by 2's, 3's or even 10's when there's not 
a lot going on.

In other words, I don't think we want a _highfrequency_ timer, I want a
_lower_ frequency mode.

So let's say that we raise HZ to 2000, or somethign that we decide is the
upper limit of sanity. We then have some timer logic entity that notices
that nothing is going to care for the next 100 ticks, so we go into "slow
mode", and reprogram the timer to tick at a frequency of 100Hz, but when
it does tick, we just count it as 20.

IOW, nothing ever sees any "variable frequency", and there's never any 
question about what the timer tick is: the timer tick is 2kHz as far as 
everybody is concerned. It's just that the ticks sometimes come in 
"bunches of 20".

This also means that there is never any issue of the timer running wild. 
The _most_ it will ever run at is limited quite naturally, and some crazy 
user asking for a 1ns itimer won't make any difference at all to the 
system.

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