Re: Scheduler degradation since 2.5.66

Bill Davidsen
2004-01-15T00:50:12Z

George Anzinger wrote:

> We get the request at some time t between tick tt and tt+1 to sleep for
> N ticks.
> We round this up to the next higher tick count convert to jiffies
> dropping any fraction and then add 1. So that should be 2 right? This
> is added to NOW which, in the test code, is pretty well pined to the
> last tick plus processing time. So why do you see 3?
>
> What is missing here is that the request was for 1.000000 ms and a tick
> is really 0.999849 ms. So the request is for a bit more than a tick
> which we are obligated to round up to 2 ticks. Then adding the 1 tick
> guard we get the 3 you are seeing. Now if you actually look at that
> elapsed time you should see it at about 2.999547 ms and ranging down to
> 1.999698 ms.

Clearly the rounding between what you want and the resolution of the
hardware tick is never going to be perfect if there is a non-integer
ratio between the values. If this is a real concern, you can play with
the algorithm and/or go to a faster clock. Or both.

You might also be much happier simply setting target times 2ms apart,
and sleeping for target-NOW ns. That allows for the processing time.

If the kernel had a better idea of when the next tick would be instead
of assuming counting from NOW instead of "last tick" you could probably
do better, but I'm not suggesting that overhead be added to the ticks
code in case someone needs a better nanosleep. I don't know how well
that would work in the SMP case in any event. Sort of
wait_ticks = 1 + int((NOW + delay - time_since_last_tick)/ns_per_tick)
or
wait_ticks =
int((NOW-delay - time_since_tick + ns_per_tick - 1)/ns_per_tick)

I think there's too much caution about going over, but without playing
with the code I'm just dropping ideas.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979