Re: HZ, preferably as small as possible

[torvalds@transmeta.com (Linus Torvalds)]

In article <59885C5E3098D511AD690002A5072D3C02AB7F88@orsmsx111.jf.intel.com>,
Grover, Andrew <andrew.grover@intel.com> wrote:
>
>But on the other hand, increasing HZ has perf/latency benefits, yes? Have
>these been quantified?

I've never had good reason to believe the latency/perf benefits myself,
but I was approached at OLS about problems with something as simple as
DVD playing, where a 100Hz timer means that the DVD player ends up
having to busy-loop on gettimeofday() because it cannot sanely sleep due
to the lack in sufficient sleeping granularity.

You apparently end up visibly missing frames - a frame is just 3 timer
ticks at 100 Hz, and considering that the kernel has to round up by one
due to POSIX requirements _and_ considering that you lose roughly one
for actually processing the frame itself, that doesn't sound _that_
outlandish. 

>		 I'd either like to see a HZ that has balanced
>power/performance, or could we perhaps detect we are on a system that cares
>about power (aka a laptop) and tweak its value at runtime?

Runtime tweaking is not really an option with the current setup. There
are also divisions etc that really want it to be a compile-time constant
for efficiency.

As noted, even power/performance-wise a higher Hz can actually _help_. 
Especially on laptops.  Exactly because you actually sanely _can_ afford
to sleep, which you cannot with a 100Hz timer. 

So you lose some, you win some, depending on your needs.

There is, of course, the option to do variable frequency (and make it
integer multiples of the exposed "constant HZ" so that kernel code
doesn't actually need to _care_ about the variability). There are
patches to play with things like that.

		Linus