Main Area and Open Discussion > General Software Discussion

Small Linux kernal patch = big improvement in desktop experience

<< < (4/4)

Edvard:
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 ranting 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  :P ) descriptions of what exactly is happening.

Edvard:
A fairly lively article at technewsworld reveals a few key arguments:
http://www.technewsworld.com/story/71328.html
'Do It Once and Leave It Built-In'

"The kernel patch groups processes by owning TTY. The bash shell change groups them by session," wrote Slashdot blogger Anonymous Coward, citing an explanation (for subscribers) on LWN.

Alternatively: "The differences between the change to the kernel and the shell script are basically two: one, they apparently have slightly different algorithms for choosing how to group the processes," brion wrote.

"That's not due to it being in-kernel vs out-of-kernel, though -- that's just because they are slightly different," brion added. "Both can be implemented in both ways, and both work with the same actual implementation mechanism -- simply one works from userspace through the interfaces and one's built-in to the kernel."

Auto-tuning behavior "that's built in will probably be the most reliable, easiest, and best-performing way to do this, rather than requiring every Linux distribution to ensure that they're running the same extra scripts and keeping the userspace stuff in sync," brion concluded. "Do it once and leave it built-in to the kernel."

And again: "One requires a kernel patch. One uses functionality *already present in the kernel* to do the same thing," chimed in spun. "Testing reveals the one that doesn't require a kernel patch is more responsive. You tell me which is best."
--- End quote ---

Navigation

[0] Message Index

[*] Previous page