* Al Boldi <[EMAIL PROTECTED]> wrote: > > 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. > [...]
nope, i cleared the stats after i laid the glxgears out, via: for N in /proc/*/sched; do echo 0 > $N; done and i did the strace (which showed a 1+ seconds latency) while the glxgears was not manipulated in any way. > [...] You see, gears sleeps when it is covered by another window, > [...] none of the gear windows in my test were overlaid... > [...] 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. that's plain wrong - at least in the test i've reproduced. In any case, if that were the case then that would be visible in the stats. So please send me your cfs-debug-info.sh output captured while the test is running (with a CONFIG_SCHEDSTATS=y and CONFIG_SCHED_DEBUG=y kernel) - you can download it from: http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh for best data, execute this before running it: for N in /proc/*/sched; do echo 0 > $N; done > 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. sure, send them along or upload them somewhere - but more importantly, please send the cfs-debug-info.sh output. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
