|From:||Nikos Chantziaras <realnc-AT-arcor.de>|
|To:||Ingo Molnar <mingo-AT-elte.hu>|
|Subject:||Re: BFS vs. mainline scheduler benchmarks and measurements|
|Date:||Thu, 10 Sep 2009 20:53:56 +0300|
|Cc:||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|
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 >> 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 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.
Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds