I was hoping you'd chime in, I figured you'd know a lot more about this stuff than I do.
RE: server vs. desktop:
To clarify, 'Desktop' means to me a graphical environment with applications launched by clicking a mouse on a menu item or icon, etc.
'Server' would then mean a text environment with mostly services and utilities typically launched from script or typing commands in a TTY (virtual login terminal) of which Linux normally reserves 7.
More could be said about that, but I wish to be brief...
According to Lennart's
comments, since the kernel patch only groups things per a given TTY, typical desktop applications wouldn't benefit directly
because their origin is a graphical environment in userspace and therefore wouldn't be bound to any TTY-based 'cgroup'.
His alternate method does it's mojo in userspace and not bound by TTY.
Tests by somebody (I can't remember who now) showed that the alternate method increased perceived
desktop performance at least as well as the kernel patch, and evenput forth numbers numbers to back it up.
That said, I can see how the kernel patch would help perceived
(hehe, I said it again...) desktop performance because background processes in a typical desktop environment are normally started pre-X11 in the startup process, (therefore bound to TTY's and herded into their cgroups) thus leaving computing power left over for the graphical interface.
Also, isn't it true that X11 is itself
bound to TTY8, so it wouldn't exactly be left out of the party, right?
You are correct about the "visibility" versus "silent magic" discussion.
Apparently, Mr. Poettering's argument lies with his opinion that a userspace implementation will benefit typical desktop users better, and the numbers appear to bear that out.
Linus likes the 'silent magic' of the kernel option because it "just works", i.e. it benefits everybody; from server admin to kernel hacker to Joe Desktop, and all it takes is to have it available in the kernel as a routine function of the scheduler.
MY question would be could these two methods be employed concurrently, (in other words, would there be any conflicts which would make performance even worse)?
If so, would it work by separating kernelspace and userspace "cgrouping"?
Like you said, we need plain english (or your preferred language pack
) descriptions of what exactly is happening.