[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070829064303.GA32371@elte.hu>
Date: Wed, 29 Aug 2007 08:43:03 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Al Boldi <a1426z@...ab.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Mike Galbraith <efault@....de>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
Keith Packard <keith.packard@...el.com>
Subject: Re: CFS review
* Al Boldi <a1426z@...ab.com> 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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists