Re: Scheduler degradation since 2.5.66

[Nick Piggin <piggin@cyberone.com.au>]

Nick Piggin wrote:

>
>
> Guillaume Foliard wrote:
>
>> Hello,
>>
>> I have been playing with kernel 2.5/2.6 for around 6 months now. I 
>> was quite pleased with 2.5.65 to see that the soft real-time 
>> behaviour was much better than 2.4.x. Since then I tried most of the 
>> 2.5/2.6 versions. But recently someone warned me about some 
>> degradations with 2.6.0-test6. To show the degradation since 2.5.66 I 
>> have run a simple test program on most of the versions. This simple 
>> program is measuring the time it takes to a process to be woken up 
>> after a call to nanosleep.
>> As the results are plots, please visit this small website for more 
>> information : http://perso.wanadoo.fr/kayakgabon/linux
>> I'm ready to perform more tests or provide more information if 
>> necessary.
>>
>
> This isn't a problem with the scheduler, its a problem with 
> sys_nanosleep.
> jiffies_to_timespec( {1000000us} ) returns 2 jiffies, and nanosleep adds
> an extra one and asks to sleep for that long (ie. 3ms).


I think you should actually sleep for 2 jiffies here. You have asked
to sleep for _at least_ 1 real millisecond and you really don't care
about the number of jiffies that is. Depending on when the last timer
interrupt had fired, the next jiffy might be in another microsecond.

So I think you really must sleep for that extra jiffy (but 3 is too
many I think). Notice your first graphs are actually bad, because
some sleeps are much less than 1000us.

I don't know much about the timer code though, perhaps you do need to
sleep for 3 jiffies...

>
> The more erratic timings could be due to interactivity changes as you 
> say,
> but you probably aren't running without RT priority


s/without/with