Alternative To the 200-Line Linux Kernel Patch 402
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."
Any linux kernel? (Score:3, Interesting)
Re:which one is 'right'? (Score:5, Interesting)
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
While the bashrc approach may seem attractive (Score:5, Interesting)
Re:which one is 'right'? (Score:4, Interesting)
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.
Poettering is pimping systemd (Score:3, Interesting)
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...
Re:Ubuntu instructions incorrect (Score:1, Interesting)
It's fixed now
Re:Also from the article (Score:2, Interesting)
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.
Re:Also from the article (Score:1, Interesting)
Way to not put two and two together.
Why not just "convince" the distros to upgrade the kernel when kernel.org's official version comes out? Ubuntu even has "Automatic Updates".
Lennart is right - the kernel patch is the hack. (Score:5, Interesting)
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!
Re:Ah the beauty of the interconnected world... (Score:3, Interesting)
Re:Seems like a good plan (Score:2, Interesting)
except some people (*cough*unbuntufolks*cough*) don't like to use the terminal... so the kernel patch might be better, although wouldn't all gui apps have the same [p]tty?
Re:Poettering is pimping systemd (Score:4, Interesting)
not multiseat support kills using pulseaudio for me. I need 3 seats all working at the same time. "htpc/wife's instance", mpd (server run as a seperate user so that not everyone has the ability to play with shit they shouldn't, and my desktop instance.
Until he gets his head out of his ass, and starts supporting the systemwide server, I'm not really going to touch it.
I have a multi user OS, and i like using it that way.
Re:But But But But Buzt Buut (Score:3, Interesting)
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 [slashdot.org] 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?
Re:Also from the article (Score:5, Interesting)
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.
Re:Whee... (Score:1, Interesting)
This attitude is what separates so many of the "middle" staff from the "upper" ones. It is also why so many middle ones *hate* their upper managers.
You forget that at some point in your career you were not this knowledgeable, indeed, I bet you can find at least one instance in the last five years where you had what you felt was a reasonable question (and I bet those reasons were well founded), asked a question, and got pounded on by experience people. There are, certainly, stupid questions (I have a friend that always wanted to reply to the statement "There are no bad questions" with "How much do my arm pits weigh"), but questions are from their very nature asked with respect to ignorance. Sadly many can not separate the too.
So, I'll give my own experience (you can decide if it is stupid or not). I'm currently working on a SCSI pass-through project that connects to a VERY demanding initiator (we can argue the virtues or lack thereof all we want - I'm not in a position to change any of that). I'm evaluating a number of Open-Source projects. this particular one behaves in a near perfect manner to what I need, in all but one place it is as perfect as if I had specced the project to our specifications. However in this one case it doesn't work - that is a check condition generated upon a buss reset - I need one byte changed to reflect that an extended part of the protocol is being used and 8 bytes added to the payload. This is not - for quite good reasons - not something a normal user needs to change, however I *have to* to have it work. It isn't something that is set up during the command structures I see from the trace debug statements, for the internal functions there are quite a few "default" values that are spread out in the code. I asked where this is set as I can't find it.
The answer? My initiator shouldn't work that way - yea, that's helpful. I, frankly agree with you - yet not a thing I can do about it. Given that this was the author of the software and what was said it would have been *easier* to tell me where to fix it. Most likely not a hard change if you know where to look but not really an easy one to grep out of the source code. If I can hack it in then I'll use the project, if not then I'll go elsewhere (and maybe even back to a high cost proprietary project - Open is great, but having a project that actually works is even better).
That attitude permeates so many Open Source projects, it is one of the larger impediments to wide-spread acceptance. Even if we assume I am quite a bad programmer the fact that I have, in the past, gotten similar project to work means I'm better off than someone who can't really figure out why Firefox in its offline mode isn't doing much to download webpages. Yet the latter is who pays most of our bills. We (software engineers), as a group, are one of the most socially defunct group on the planet. I certainly qualify for that, though luckily or unluckily (depending on how you view it) mine tend to be towards personal relationships and I can quite easily deal even with truly stupid questions on a project. It seems that so many software engineers can't figure out why people who have not spent the last five years of their live also studying this tiny fraction of the world doesn't have the understanding that those that did so have.
Re:Also from the article (Score:1, Interesting)
Lennart is being himself but his point stands 100%: The kernel config option description "optimizes the scheduler for common desktop workloads" is clearly untrue. This only helps hard core developers who also watch videos on the side -- and that's awesome but trying to market this as fixing something for the "desktop use case" is bollocks: normal desktop users do not have multiple TTYs running their apps.
Re:Also from the article (Score:5, Interesting)
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.
Re:Any linux kernel? (Score:3, Interesting)
For the Qualcomm Android platform and generally most smartphones, the radio stack/base-band/etc on a different processor running a RTOS. Makes it really hard to hack too.
It is quite safe to mess with the scheduler for the "user" application processor.
Ubuntu's Code of Conduct (Score:3, Interesting)
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/ [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 [ubuntu.com]