Re: dynamic-hz

[Nish Aravamudan]

On Mon, 13 Dec 2004 13:51:11 +0100, Hans Kristian Rosbach
<hk@xxxxxxxxxxx> wrote:
> 
> 
> 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?

schedule_timeout() specifies a sleep in jiffies -- it's actually a
rather annoying interface for the very reason that it depends on the
value of HZ how *long* you actually will sleep for (in human time
units). So your assumption is incorrect, presuming the code author
knows what they are doing. They wish to sleep for 1/10 the number of
timer ticks in a second. What this translates to, though, clearly
depends on HZ. Thus

msleep{,_interruptible}(100);

would be far better to use (it calls schedule_timeout() correctly
[another thing not done often]). Also, if you look carefully at the
timer code, you'll notice that the x86 timer frequency is not actually
1000 Hz, it's actually less. Thus you run into issues with timer
intervals... But, in any case, specifying a timeout of 100 msecs is
different then specifying a timeout of 100 cycles on x86. I'm not sure
what it exactly translates to, but it will be more. Hence, you should
use msleep() not schedule_timeout() directly. Jiffies should not be
what you base your timing on; msecs & secs are easier and less likely
to be misused.

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

No, please don't. Use msleep() or msleep_interruptible(). Let the
conversion functions take care of the conversions.

> 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?

No floating point in the kernel...

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