Re: HZ, preferably as small as possible

[Linus Torvalds]

On Wed, 17 Jul 2002, Daniel Phillips wrote:
>
> We don't have to feel restricted to integer multiples.  I'll paste in my
> earlier post, for your convenience:

Oh, I agree. I think the integer multiplies simplify the problem space,
and should be trivial for most timer hardware (ie most timer hardware is
likely just a counter, so making the countdown value be N times as big
just automatically gives you integer multiples).

The _important_ part I would prefer people to take away is that it is
easier to "slow down" the clock than it is to speed it up. Mainly because
the place that are likely to care about speeding it up are also very very
timing-critical. For example, there is no way in _hell_ that we're going
to reprogram the old-style PC/AT timer inside the "add_timer()" function.
It just is not viable.

In contrast, the places who are interested in slowing the timer down are
also the places likely to not be as timing-critical. The idle loop being
the perfect example (and also being right now the _only_ example where
somebody actually asked for a slower timer tick).

Also note that once you're willing to do this in the slow path, you can
also do real "fixups" to the results since you can afford to take a small
hit when you get back to "fast mode". For example, if we only do this on
PC's while we go into C3 anyway (where latencies to saving power are quite
noticeably anyway, so that the idle loop already has to do some latency
estimation before it decides to go into C3), then we can easily afford to
completely re-setting not just the timer counter, but doing fairly complex
things like re-adjusting the whole time-of-day clock.

See how it becomes a much simpler game (and you have more options) if you
take the "slow the timer down when idle" approach instead of taking the
"speed the timer up when you need to" approach?

			Linus