Re: dynamic-hz

[Andrea Arcangeli <andrea@suse.de>]

On Mon, Dec 13, 2004 at 03:25:21AM -0800, Andrew Morton wrote:
> We still have 1000-odd places which do things like
> 
> 	schedule_timeout(HZ/10);
> 
> which will now involve a runtime divide.  The propagation of msleep() and
> ssleep() will reduce that a bit, but not much.

The above is by far the least cpu-hungry piece, it's going to sleep for
100msec, so any order-of-nanoseconds computation in such path will be by
defininition not measurable.

msleep and ssleep as well will obviously be non measurable for the same
reason (their only point is to wait and "waste" cpu). I mean,
msleep/ssleep are the only places in the kernel that we don't really
need to optimize ;). 

Most other fast paths can't execute the division or multiplication at
compile time anyway, so they'd only save 1 cacheline (at the expense of
a bit larger icache).

> It's so simple to turn all those into compile-time divides that we may as
> well do it.

I'm not against leaving a compile time option, it's absolutely trivial
to add it, but I just don't think it'll provide any measurable benefit
in practice, while the ability to switch HZ provides tantible benefits
(even to be able to set HZ to higher frequencies than 1khz, so that
people can post a nanosleep call that will return in 0.1msec instead of
1msec).

Perhaps __HZ could hurt a bit on a NUMA box where the icache may be
spread on the local nodes and the __HZ not, but then the __HZ could be
made a __per_cpu variable conditionally to NUMA and they would get
dynamic settable hz too, which I believe is significant for a numa box
since if they're doing just userspace computing they don't need a fast
HZ and they can get back 1% of their cpu power from every cpu in the
system (on a 512-way system that's quite a lot more than what you will
ever get back from HZ set at compile time ;).