Slashdot Mirror
Alternative To the 200-Line Linux Kernel Patch
climenole writes "Phoronix recently published an article regarding a ~200 line Linux Kernel patch that improves responsiveness under system strain. Well, Lennart Poettering, a Red Hat developer, replied to Linus Torvalds on a mailing list with an alternative to this patch that does the same thing yet all you have to do is run 2 commands and paste 4 lines in your ~/.bashrc file."
Will this work on more than just x86, for example a rooted Android phone? I might try this now.
After logging in slashdot still does not take you back to the page you were on. It's been that way for 20 years.
I've done some tests and the result is that Lennart's approach seems to work best. It also _feels_ better interactively compared to the vanilla kernel and in-kernel cgrougs on my machine. Also it's really nice to have an interface to actually see what is going on. With the kernel patch you're totally in the dark about what is going on right now.
-Markus Trippelsdorf
right from the article
this is definitely one of those things that I add now, then forget about later, and it becomes a condition that may or may not work when I apply upgrades & patches in the future. Whether or not the .bashrc approach is faster, I think that going down the kernel route makes it more consistently usable.
One requires a kernel patch. One uses functionality already present in the kernel to do the same thing. Testing reveals the one that doesn't require a kernel patch is more responsive. You tell me which is best.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Poettering wants scheduling to be handled by his "systemd", a replacement to init/upstart. This, by the way, is the developer of Pulseaudio, so those of you who've experienced broken sound in recent years can now look forward to broken system initialization, coming soon to a Linux distribution near you...
Linus is right about not requiring user setup. It's a usability thing.
However I disagree with the conclusion that the patch should therefore be merged into the kernel. First, instead of pasting some lines to bashrc and running some commands, the user now has to recompile to kernel to benefit from the change. That's a lot less user friendly. Secondly, if one really wants to push user friendliness, one should convince distributions to update their init scripts to run those cgroup commands automatically. Since all software users use go through distros anyway it should be the distros' job to ensure user friendliness.
The kernel patch is the hackish way to do it. They're hard-coding policy settings into a kernel patch. Dumb. The kernel is there to provide the knobs, not to twiddle them for you.
Lennart's argument is that policy should not be hard-coded into the kernel. He's not saying "everyone should do this in a bash script". He's saying "leave policy settings to userspace mechanisms that can handle them better." Say, systemd for instance.
Users would be better served by Lennart's approach, I think.
Funny thing is, most desktop users will not see the benefits of the patch, since most of them never use the terminal to run cpu-hogging kernel builds. All desktop apps share the same cgroup.
That won't stop hordes of n00bs from claiming ZOMG MAI SYSTEM IS SO MUCH FA$TER NOW OMG!
Considering that Lennart wrote the steaming, broken pile known as PulseAudio, his solution makes perfect sense...
I see the GP is well on his way to earning the elusive (Score:5, Troll) achievement which is one of the rarest drops on Slashdot (BTW, when did Slashdot turn into XBox Live with achievements? Now, get off my lawn...)
Just an FYI, your ad hominem attack does not detract from his legitimate point. I am well aware of the technical issues involved, but at some point you have to stop giving Linux & X Windows a pass just because Unix/X was crappily designed in this regard back in the 70's (tty's and client/server GUI apps). If stuttering media playback is a side effect of the present modular paradigm, then perhaps it is time to stop making excuses for it.
This is almost as bad as when people stepped up to defend the ext4 data loss / commit interval issue to say it was "by design". Yeah, it is trivial to avoid by calling fsync in your app all the time, but watch that destroy perf because it flushes the whole I/O queue for the system. Ordered data mode just makes sense... strange that wouldn't be default, or even an option to turn off if you think about it. So, what's a cautious app designer to do? Fsync all the time? Can a userspace app even query this flag? And no, using SQLite is not a legitimate workaround.
Same damn thing when Linux zealots call ZFS a "rampant layering violation" and then define away innovative capabilities like RAIDZ and cheap, versatile COW snapshots as "nonfeatures" because they can't be replicated while abiding within the Linux layering paradigm. Sour grapes, indeed. Btfs won't be able to replicate these features unless they break the layering paradigm, so who wants those features anyway?
Soooooo... watch me get flayed alive for my heresy: I say if the extant paradigm isn't optimal, then maybe it's time to consider changing it. At the very least, it's intellectually dishonest to claim that these aren't problems just because there are no simple fixes in the present model. As noted by others, this "fix" is essentially a heuristic with improved granularity for the given problem. Good, at least that's something. Now, how about the real, underlying problem?
What I don't get is why he uses
if [ "$PS1" ]; then
instead of
if [ -t 0 ]; then
Why the latter? Because it works, that's why:
# sh -c '[ "$PS1" ] && echo tty detected'
#
# sh -c '[ -t 0 ] && echo tty detected'
tty detected
The other way around, if a user has set PS1 in .profile, you'll get false positives, and cron jobs that will consume more than their fair share of resources.
There is no one single magic bullet to say do XYZ and the desktop usage will be super awesome responsive. That is because there are different situations and conditions that can affect performance.
This specific patch is to handle the case where running background tasks (updating, backup, searching the filesystem to index files and other things the computer can do) that eat up CPU causes the system to become unresponsive (especially on lower spec machines that don't have enough CPUs to handle moderately complex workloads). The reason the "make -j64" was used was not to say that this is great for developers or people building stuff in the background while watching video (which it will be), but to simulate the system under stress.
This was fixed in 2004, with Ubuntu's Code of Conduct. Telling people RTFM is forbidden, either you help or shut up. People sometimes wonder whats the big deal with Ubuntu, and I'm positive this is one of the main reasons. You can check the forum http://ubuntuforums.org/ or hop to Freenode's #ubuntu channel to see this policy in action. No matter how repeated or simple a question is, it is allowed and if you reply, it is to help, even if thats pointing someone to a well written help page (like the many at help.ubuntu.com).
That policy is written in detail here: http://www.ubuntu.com/community/conduct
Artix
Your Linux, your init.