Message-ID: <4AA93D34.8040500@arcor.de>
Date:	Thu, 10 Sep 2009 20:53:56 +0300
From:	Nikos Chantziaras <realnc@...or.de>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Jens Axboe <jens.axboe@...cle.com>, Mike Galbraith <efault@....de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Con Kolivas <kernel@...ivas.org>, linux-kernel@...r.kernel.org
Subject: Re: BFS vs. mainline scheduler benchmarks and measurements

On 09/10/2009 09:08 AM, Ingo Molnar wrote:
>
> * Nikos Chantziaras<realnc@...or.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists