Re: Scheduler degradation since 2.5.66

[Bill Davidsen <davidsen@tmr.com>]

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