|| ||Nikos Chantziaras <realnc-AT-arcor.de> |
|| ||Ingo Molnar <mingo-AT-elte.hu> |
|| ||Re: BFS vs. mainline scheduler benchmarks and measurements |
|| ||Thu, 10 Sep 2009 20:53:56 +0300|
|| ||Jens Axboe <jens.axboe-AT-oracle.com>, Mike Galbraith <efault-AT-gmx.de>,
Peter Zijlstra <a.p.zijlstra-AT-chello.nl>,
Con Kolivas <kernel-AT-kolivas.org>, linux-kernel-AT-vger.kernel.org|
|| ||Article, Thread
On 09/10/2009 09:08 AM, Ingo Molnar wrote:
> * Nikos Chantziaras<email@example.com> wrote:
>> With your version of latt.c, I get these results with 2.6-tip vs
>> Max 50 usec
>> Avg 12 usec
>> Stdev 3 usec
>> 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
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 126.96.36.199 (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 post comments)