Re: CFS review

[Al Boldi <a1426z@gawab.com>]

Ingo Molnar wrote:
> * Al Boldi <a1426z@gawab.com> wrote:
> > I have narrowed it down a bit to add_wait_runtime.
>
> the scheduler is a red herring here. Could you "strace -ttt -TTT" one of
> the glxgears instances (and send us the cfs-debug-info.sh output, with
> CONFIG_SCHED_DEBUG=y and CONFIG_SCHEDSTATS=y as requested before) so
> that we can have a closer look?
>
> i reproduced something similar and there the stall is caused by 1+
> second select() delays on the X client<->server socket. The scheduler
> stats agree with that:
>
>  se.sleep_max             :          2194711437
>  se.block_max             :                   0
>  se.exec_max              :              977446
>  se.wait_max              :             1912321
>
> the scheduler itself had a worst-case scheduling delay of 1.9
> milliseconds for that glxgears instance (which is perfectly good - in
> fact - excellent interactivity) - but the task had a maximum sleep time
> of 2.19 seconds. So the 'glitch' was not caused by the scheduler.

2.19sec is probably the time you need to lay them out side by side.  You see, 
gears sleeps when it is covered by another window, so once you lay them out 
it starts running, and that's when they start to stutter for about 10sec.  
After that they should run smoothly, because they used up all the sleep 
bonus.

If you like, I can send you my straces, but they are kind of big though, and 
you need to strace each gear, as stracing itself changes the workload 
balance.

Let's first make sure what we are looking for:
1. start # gears & gears & gears &
2. lay them out side by side, don't worry about sleep times yet.
3. now they start stuttering for about 10sec
4. now they run out of sleep bonuses and smooth out

If this is the sequence you get on your machine, then try disabling 
add_wait_runtime to see the difference.


Thanks!

--
Al