Re: BFS vs. mainline scheduler benchmarks and measurements
From: Nikos Chantziaras
Date: Thu Sep 10 2009 - 13:54:07 EST
On 09/10/2009 09:08 AM, Ingo Molnar wrote:
* Nikos Chantziaras<realnc@xxxxxxxx> wrote:
With your version of latt.c, I get these results with 2.6-tip vs
2.6.31-rc9-bfs:
(mainline)
Averages:
------------------------------
Max 50 usec
Avg 12 usec
Stdev 3 usec
(BFS)
Averages:
------------------------------
Max 474 usec
Avg 11 usec
Stdev 16 usec
However, the interactivity problems still remain. Does that mean
it's not a latency issue?
It means that Jens's test-app, which demonstrated and helped us fix
the issue for him does not help us fix it for you just yet.
The "fluidity problem" you described might not be a classic latency
issue per se (which latt.c measures), but a timeslicing / CPU time
distribution problem.
A slight shift in CPU time allocation can change the flow of tasks
to result in a 'choppier' system.
Have you tried, in addition of the granularity tweaks you've done,
to renice mplayer either up or down? (or compiz and Xorg for that
matter)
Yes. It seems to do what one would expect, but only if two separate
programs are competing for CPU time continuously. For example, when
running two glxgears instances, one with nice 0 the other with 19, the
first will report ~5000 FPS, the other ~1000. Renicing the second one
from 19 to 0, will result in both reporting ~3000. So nice values
obviously work in distributing CPU time. But the problem isn't the
available CPU time it seems since even if running glxgears nice -20, it
will still freeze during various other interactive taks (moving windows
etc.)
[...]
# echo NO_NEW_FAIR_SLEEPERS> /debug/sched_features
Btw., NO_NEW_FAIR_SLEEPERS is something that will turn the scheduler
into a more classic fair scheduler (like BFS is too).
Setting NO_NEW_FAIR_SLEEPERS (with everything else at default values)
pretty much solves all issues I raised in all my other posts! With this
setting, I can do "nice -n 19 make -j20" and still have a very smooth
desktop and watch a movie at the same time. Various other annoyances
(like the "logout/shutdown/restart" dialog of KDE not appearing at all
until the background fade-out effect has finished) are also gone. So
this seems to be the single most important setting that vastly improves
desktop behavior, at least here.
In fact, I liked this setting so much that I went to
kernel/sched_features.h of kernel 2.6.30.5 (the kernel I use normally
right now) and set SCHED_FEAT(NEW_FAIR_SLEEPERS, 0) (default is 1) with
absolutely no other tweaks (like sched_latency_ns,
sched_wakeup_granularity_ns, etc.). It pretty much behaves like BFS now
from an interactivity point of view. But I've used it only for about an
hour or so, so I don't know if any ill effects will appear later on.
NO_START_DEBIT might be another thing that improves (or worsens :-/)
make -j type of kernel build workloads.
No effect with this one, at least not one I could observe.
I didn't have the opportunity yet to test and tweak all the other
various settings you listed, but I will try to do so as soon as possible.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/