Re: Scheduler degradation since 2.5.66

George Anzinger
2004-01-15T03:36:40Z

Bill Davidsen wrote:
> 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 then you have a better resolution. For this, see the high-res-timers patch
in my signature, which will get you much closer, but still plays by the standard
rules.

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.

The "caution" is around the standard that says "thou shalt never wake early" or
words to that effect.

--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml