Re: BFS vs. mainline scheduler benchmarks and measurements

On 09/10/2009 09:08 AM, Ingo Molnar wrote:
>
> * Nikos Chantziaras<realnc@arcor.de>  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.