Messages in this thread | | | Date | Mon, 13 Dec 2004 20:05:34 -0800 | From | Nish Aravamudan <> | Subject | Re: dynamic-hz |
| |
On Mon, 13 Dec 2004 13:51:11 +0100, Hans Kristian Rosbach <hk@isphuset.no> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |