Messages in this thread | | | Date | Tue, 08 Sep 2009 10:19:06 +0300 | From | Nikos Chantziaras <> | Subject | Re: BFS vs. mainline scheduler benchmarks and measurements |
| |
On 09/07/2009 05:40 PM, Arjan van de Ven wrote: > On Mon, 07 Sep 2009 06:38:36 +0300 > Nikos Chantziaras<realnc@arcor.de> wrote: > >> On 09/06/2009 11:59 PM, Ingo Molnar wrote: >>> [...] >>> Also, i'd like to outline that i agree with the general goals >>> described by you in the BFS announcement - small desktop systems >>> matter more than large systems. We find it critically important >>> that the mainline Linux scheduler performs well on those systems >>> too - and if you (or anyone else) can reproduce suboptimal behavior >>> please let the scheduler folks know so that we can fix/improve it. >> >> BFS improved behavior of many applications on my Intel Core 2 box in >> a way that can't be benchmarked. Examples: > > Have you tried to see if latencytop catches such latencies ?
I've just tried it.
I start latencytop and then mplayer on a video that doesn't max out the CPU (needs about 20-30% of a single core (out of 2 available)). Then, while the video is playing, I press Alt+Tab repeatedly which makes the desktop compositor kick-in and stay active (it lays out all windows as a "flip-switch", similar to the Microsoft Vista Aero alt+tab effect). Repeatedly pressing alt+tab results in the compositor (in this case KDE 4.3.1) keep doing processing. With the mainline scheduler, mplayer starts dropping frames and skip sound like crazy for the whole duration of this exercise.
latencytop has this to say:
http://foss.math.aegean.gr/~realnc/pics/latop1.png
Though I don't really understand what this tool is trying to tell me, I hope someone does.
| |