[gentoo-user] Re: FYI - 2.6.38 desktop responsiveness patch + how to do it now

[Nikos Chantziaras]

On 11/19/2010 11:46 PM, Alan McKinnon wrote:
> Apparently, though unproven, at 18:03 on Friday 19 November 2010, Nikos
> Chantziaras did opine thusly:
>
>>> Perhaps distros will pick up on this and offer other criteria, maybe
>>> something like a profile selectable at boot-time or maybe even runtime.
>>>
>>> What I would like to see is flash goes into it's own group and gets
>>> throttled. Everything else running under KDE is in a different group and
>>> left to run full speed
>>
>> I was kind of hoping this would give results in the same league as the
>> BFS patch, but it seems it something that needs tweaking and doesn't
>> "just work for everything."  It doesn't look like it's for desktop
>> users, only for "make -j999" people.
>
> Maybe I expected more, but I don't seem to feel the improvement in Con's
> scheduler. Perhaps it's a perception thing.
>
> About two months ago I did reboot into a gentoo kernel and things did feel a
> little different but not in a way I could put my fingers on. I put it down to
> running a huge compile in screen. I *do* feel the incremental improvements in
> KDE since about 4.3, mostly because new versions come out rapidly.
>
> What do you perceive with BFS vs mainline/gentoo/whatever?

Less stalls in animations.  A classic example is mplayer stalling when I 
move the mouse over the clock to the right of the system tray in KDE. 
KDE will fade-in a pop-up that contains details about the current date. 
  For the duration of the fade-in, mplayer will stop playing frames. 
This is a "stall."  It seems that the compositor of KDE gets way more 
CPU than it should resulting in mplayer starving for CPU.  With BFS, 
this does not happen.

Also the reverse happens too.  For example, if something is eating CPU, 
the GUI can stall for a few moments.  Like minimizing a window in KDE. 
This zooms-out the window towards the task bar.  Without BFS, the 
zoom-out animation will sometimes stop in mid-way for a few milliseconds 
if something else if producing heavy load on the machine.  This also 
happens less often with BFS.

Another example is sound latency in audio apps (synths and such.)  A 
realtime kernel is extreme overkill for this use.  BFS also helps here.

It would seem that this "200 line patch" is not good at solving those 
issues; it solves them only for stuff launched from the terminal, since 
they have their own TTY assigned to them.  What I like about BFS is that 
this gets solved automatically in a "run it and forget it" way.  There's 
nothing to set up or tweak.

However, it should be mentioned that mainline became much better on the 
desktop in recent releases.  2.6.36 for example is much closer to BFS 
than 2.6.31 which kind of totally sucked and was one of the triggers 
that lead to BFS.

(I actually use the whole 2.6.36-ck1 patchset, not just the BFS patch. 
You can find more info at http://ck-hack.blogspot.com .)