Re: dynamic-hz

[Hans Kristian Rosbach <hk@isphuset.no>]

On Mon, Dec 13, 2004 at 12:22:29PM +0100, Pavel Machek wrote:
> I tried defining HZ to 10 once, and there are some #if arrays in the
> kernel that prevented me from doing that.
> 
> Some drivers do timeouts based on jiffies; having HZ=1 may turn 20msec
> timeout into 1sec, that could hurt a lot in the error case...

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.

Shouldn't that be regarded as a bug/deprecated?

I'm not sure what the above "scedule_timeout(HZ/10)" is supposed to
do, but the parameter it gets in 1000hz is "100" so I assume this
is because we want to wait for 100ms, and in 1000hz that equals
100 cycles. Correct?

If so, I guess this calculation would fix that problem, but I guess
this is also what Andrew referred to as the extra runtime division?

wait-ms/(1000/hz) = hz-to-wait
100/(1000/1000) = 100 == 100ms
100/(1000/100)  = 10  == 100ms
100/(1000/50)   = 5   == 100ms

It would of course be optimized to something like this:
wait-ms/ms-per-hz

What about this:
At startup time we set a global variable based on hz:
varX = HZ/1000;

then in the rest of the code we can use ex:
schedule_timeout(varX*100) for 100ms no matter what hz is.

With hz=50 then the lowest ms is 20 for one tick though. And that
might trigger problems with approximation at some point.
varX would have to be decimal, and that might also be a problem?

I think that extremists will push the limits on these settings,
and that failure due to wrong timouts or other similar things
would generate unwanted noise on LKML.

I think I'm just stating about the obvious now, am I not?

-HK