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

[Alan McKinnon]

Apparently, though unproven, at 23:09 on Saturday 20 November 2010, Nikos 
Chantziaras did opine thusly:

> > I'm running 2.6.36-ck-r2 and mplayer is smooth as a baby's backside - KDE
> > animations have no effect on that.
> 
> 2.6.36-ck-r2 has BFS as scheduler.  I thought your were not using BFS :-P

Perhaps I wasn't clear on that.

I was looking for some independent reinforcement that BFS actually does 
something useful and is worth continuing to use :-)


-- 
alan dot mckinnon at gmail dot com

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

[Nikos Chantziaras]

On 11/20/2010 10:55 PM, Alan McKinnon wrote:

Apparently, though unproven, at 21:25 on Saturday 20 November 2010, Nikos
Chantziaras did opine thusly:


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.


I'm running 2.6.36-ck-r2 and mplayer is smooth as a baby's backside - KDE
animations have no effect on that.


2.6.36-ck-r2 has BFS as scheduler.  I thought your were *not* using BFS :-P

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

[Alan McKinnon]

Apparently, though unproven, at 21:25 on Saturday 20 November 2010, Nikos 
Chantziaras did opine thusly:

> > 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.

I'm running 2.6.36-ck-r2 and mplayer is smooth as a baby's backside - KDE 
animations have no effect on that. The two things that do slow my desktop down 
are when nepomuk decides to do it's thing (and I still haven't found a way to 
tweak how aggresively it does that) and when kontact can't find the imap 
server on Exchange.

It's been so long since I used a vanilla or gentoo kernel I honestly can't 
recall what it was like. And testing it means a reboot. Hopefully when I next 
reboot I'll remember what to compare against.


-- 
alan dot mckinnon at gmail dot com

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

[Florian Philipp]

Am 19.11.2010 16:36, schrieb Alan McKinnon:
> Apparently, though unproven, at 17:18 on Friday 19 November 2010, Nikos 
> Chantziaras did opine thusly:
> 
>> On 11/19/2010 04:37 AM, Adam Carter wrote:
>>> 2.6.38 should contain a ~200 line patch that makes a huge difference to
>>> desktop responsiveness under load;
>>> "Tests done by Mike show the maximum latency dropping by over ten times
>>> and the average latency of the desktop by about 60 times"
>>> Ref:
>>> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1
>>> >> =1>
>>>
>>> And a RedHat dev reckons you can get the same via configuration;
>>> Ref:
>>> http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html
>>>
>>> I havent tried it yet...
>>
>> Doesn't this patch group tasks by TTY?
> 
> As I understand it, the kernel patch does group by TTY. Personally I think 
> that's just one way of doing it and there could be others. So it's more proof-
> of-concept than TheOneTrueWay(tm)
> 
[...]
> 
> 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
> 

Please help me understand what this patch/script actually does. As far
as I understand it, it groups processes so that the kernel can schedule
more fairly among them. It therefore helps to prevent one group of
processes from starving all others. Is that correct?

First question: What about heavily multi-threaded applications? Does the
kernel already make a similar grouping of threads-per-process as it does
with processes-per-cgroup? Asked in a different way: Would it have any
effect to put single but heavily multi-threaded process such as Tomcat
or Apache with Worker MPM into its own dedicated cgroup?

Second question: When I run a server with different services, does it
make sense to put all services into different cgroups? For example
PostgreSQL in the first, Apache in a second and Cron (and thereby all
batch jobs) in a third? This should be easy enough to do by editing the
init-scripts.

Thanks in advance!
Florian Philipp



signature.asc
Description: OpenPGP digital signature

[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 .)

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

[Alan McKinnon]

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?


-- 
alan dot mckinnon at gmail dot com

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

[Alan McKinnon]

Apparently, though unproven, at 23:28 on Friday 19 November 2010, Willie Wong 
did opine thusly:

> On Fri, Nov 19, 2010 at 05:36:05PM +0200, Alan McKinnon wrote:
> > Prevailing opinion on /.
> 
> That is a strange sentence itself. To see Alan deferring to the higher
> authority of the collective wisdom of /. is... well... surprising.
> 
> W


I don't browse at -1 :-)

But nonethless, your comment appears to credit me with much more intelligence 
than I actually have (that might be a mistake). Like all good Unix admins, I 
know how to bluff; and on days like today I bluff *a lot*.

Yes, today was one of those days

-- 
alan dot mckinnon at gmail dot com

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

[Willie Wong]

On Fri, Nov 19, 2010 at 05:36:05PM +0200, Alan McKinnon wrote:
> Prevailing opinion on /. 

That is a strange sentence itself. To see Alan deferring to the higher
authority of the collective wisdom of /. is... well... surprising. 

W

-- 
Willie W. Wong ww...@math.princeton.edu
Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire 
 et vice versa   ~~~  I. Newton

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

[Nikos Chantziaras]

On 11/19/2010 05:36 PM, Alan McKinnon wrote:

Apparently, though unproven, at 17:18 on Friday 19 November 2010, Nikos
Chantziaras did opine thusly:


On 11/19/2010 04:37 AM, Adam Carter wrote:

2.6.38 should contain a ~200 line patch that makes a huge difference to
desktop responsiveness under load;
"Tests done by Mike show the maximum latency dropping by over ten times
and the average latency of the desktop by about 60 times"
Ref:
http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1


And a RedHat dev reckons you can get the same via configuration;
Ref:
http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html

I havent tried it yet...


Doesn't this patch group tasks by TTY?


As I understand it, the kernel patch does group by TTY. Personally I think
that's just one way of doing it and there could be others. So it's more proof-
of-concept than TheOneTrueWay(tm)

The config and bash commands method from RedHat does things slightly
differently. Prevailing opinion on /. is that the patch method is cleaner but
more restrictive, which the userspace method is more configurable but requires
root.

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.

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

[Alan McKinnon]

Apparently, though unproven, at 17:18 on Friday 19 November 2010, Nikos 
Chantziaras did opine thusly:

> On 11/19/2010 04:37 AM, Adam Carter wrote:
> > 2.6.38 should contain a ~200 line patch that makes a huge difference to
> > desktop responsiveness under load;
> > "Tests done by Mike show the maximum latency dropping by over ten times
> > and the average latency of the desktop by about 60 times"
> > Ref:
> > http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1
> >  > =1>
> > 
> > And a RedHat dev reckons you can get the same via configuration;
> > Ref:
> > http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html
> > 
> > I havent tried it yet...
> 
> Doesn't this patch group tasks by TTY?

As I understand it, the kernel patch does group by TTY. Personally I think 
that's just one way of doing it and there could be others. So it's more proof-
of-concept than TheOneTrueWay(tm)

The config and bash commands method from RedHat does things slightly 
differently. Prevailing opinion on /. is that the patch method is cleaner but 
more restrictive, which the userspace method is more configurable but requires 
root.

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



-- 
alan dot mckinnon at gmail dot com

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

[Nikos Chantziaras]

On 11/19/2010 04:37 AM, Adam Carter wrote:

2.6.38 should contain a ~200 line patch that makes a huge difference to
desktop responsiveness under load;
"Tests done by Mike show the maximum latency dropping by over ten times
and the average latency of the desktop by about 60 times"
Ref:
http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 


And a RedHat dev reckons you can get the same via configuration;
Ref:
http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html

I havent tried it yet...


Doesn't this patch group tasks by TTY?