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."
There is a right way to do things and a hackish way. I wonder which one is which
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.
H H H how is the stut tering?
I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
Can anyone explain how the bash script / commands work? I know a fair bit about Linux but frankly this goes into device mappings at a level I've rarely had to deal with.
Is there a catch?
You spend weeks coming up with a solution, get posted on slashdot, and then some smartass hadoukens the shit out of it with simpler solution a few days later ^^
I heard that if you stick a penny to the top of your case it speeds up everything by 200%.
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.
My understanding of the original kernel patch is that it just puts stuff from different ttys into different groups for scheduling purposes so that they're less able to hog each other's resources. This alternative just makes your shell sort it out itself when it starts i.e. when you're running a new terminal. So this should basically be equivalent.
See this comment from the latest article for Linus' take on putting this stuff in-kernel:
http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html#comment-98834842
The comment here is very important to remember though:
http://linux.slashdot.org/comments.pl?sid=1870628&cid=34241622
another comment on that article (which I can't now find - anybody know where it is?) basically said that the patch suits Linus's own use of compiling kernels whilst surfing the web. Sounds like a reasonably accurate assessment really so for now it's far from the magical boost to general interactivity some may have hoped for. In some sense there's no such thing anyhow.
Nonetheless the comment linked above also has Linus talking about increasing the scope of the automatic grouping heuristics in the future so hopefully the "just works" nature of this should become available to more people eventually.
The original kernel patch (and this alternative) aren't magically making everything respond better, they just improve certain usecases.
Mounting the cgroup file system and multiplying the 4 lines by every user account on the system in order for Lennart's patch to work.
linked here http://lkml.org/lkml/2010/11/16/330
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...
Man, after reading some of that thread, those folks in kernel development make Slashdot users seem downright well-mannered.
There's a 68.71% chance you're right.
Two things:
1) There isn't a difference between the kernel patch and the command line hack. They are equivalent. The command line bit was known beforehand because that was the method used to figure out if this kernel hack would be a good idea. The kernel hack just makes the process transparent.
Linus says: Right. And that's basically how this "patch" was actually tested originally - by doing this by hand, without actually having a patch in hand. I told people: this seems to work really well.
2) Linus recommends the kernel patch:
Linus also says:Put another way: if we find a better way to do something, we should _not_ say "well, if users want it, they can do this *technical thing here*". If it really is a better way to do something, we should just do it. Requiring user setup is _not_ a feature.
Source.
Weaselmancer
rediculous.
nah, a few lines to the system-wide /etc/bash.bashrc should do just fine
Racing stripes do the same thing and are much prettier.
I find magnets work best of all.
-- Tigger warning: This post may contain tiggers! --
Isn't the good old 'nice' command intended for scheduling priority adjustments like these? Can someone explain why the 'nice' command is not suitable?
Following the instructions for Ubuntu as detailed in the post will give you an error message everytime you open gnome-terminal.
One of the comments left by Ricardo Ferreira on that page solved my problem (after rebooting again):
Edit your rc.local file with sudo gedit /etc/rc.local and delete the following line:
echo "1" > /dev/cgroup/cpu/user/notify_on_release
Save and exit gedit. Then, run gedit ~/.bashrc and add the following inside your if statement:
echo "1" > /dev/cgroup/cpu/user/$$/notify_on_release
So it should look like this:
if [ "$PS1" ] ; then /dev/cgroup/cpu/user/$$ /dev/cgroup/cpu/user/$$/tasks /dev/cgroup/cpu/user/$$/notify_on_release
mkdir -m 0700
echo $$ >
echo "1" >
fi
Do what thou wilt shall be the whole of the Law
Use the TURBO button!
The linked web page doesn't really explain what's going on. For someone who uses Unix but is far from an expert, can someone describe what's going on and why this is cool? Does it even matter if you're not into deep kernal stuff?
Or dig thru the code and figure out what the 1 is turning on and get rid of the conditional and just have it on...?
Way back when x86 processors were starting to go faster than 3 MHz, desktops built around these faster CPUs had actual turbo buttons that toggled the machine between standard and fast CPU speeds. This was because some software was built assuming a particular CPU speed. Most software would just run faster if you pushed the turbo button, but some things (particularly a lot of games) would behave weirdly or crash.
mounting anything? /etc/fstab, in worst case /etc/rc.local. modifying everyone's .bashrc? i thought there's /etc/profile for that.
In fact, they still make turbo buttons, though as on-screen controls instead of physical switches. There's a turbo button on my laptop's taskbar, called "CPU Frequency Scaling Monitor". I can turn it on, but then I get less battery life. Ordinarily, an OS is set to turn turbo on when the machine is plugged in and turn it off when running on battery power.
With my new 100/100mbit broadband, and the fastest SSD, and this hack, I'm not sure I'm noticing anything ;O
I still use csh(1), you insensitive clod!
Surely it was an "un-turbo" button, it crippled your 8086 or 80286 back down to the speed expected by certain software, not what the PC was capable of. Incidentally I'm writing this post on the keyboard which came with my 12MHz 286 1MB Decstation PC. A very nice keyboard. The Decstation case was nice but unfortunately not worth salvage. It had 3.5" full height drive bays only.
/etc/bash.bashrc
Global bashrc file.
Non impediti ratione cogitationus.
So switches or buckling spring?
The model M I am using to type this turned 20 this year. I really want an old 1986 one with a metal badge.
Luxury! Utter Luxury! In my day we did it with 4 commands and 8 lines... In the Snow!
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
IIRC, Windows favors processes with a hWnd over those without one. I guess this is roughly the same thing, but the other way around.
It's one of those tricks needed to survive on the desktop. Distros these days have become so GUI-driven that the vast majority of users never manually edit a config file, most programmers use IDEs and we all know tcpdump & nmap are for hackers :)
And I suppose most CPU-intensive software comes in a daemon flavor. I wonder how typing in a terminal is affected.
You were mod'ed "funny", but seriously, I've been using tcsh (interactively) since the 80s and prefer it to bash. I also tend to write scripts in ksh as that's been more portable and available (native) than bash on non-Linux systems - though that's changing.
It must have been something you assimilated. . . .
Applied the patch. Everything runs faster, yet loading a slashdot page still locks everything up tight. WTF is slashdot doing?
If you were looking for an example of why Linux is still awesome, this is it.
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!
I'm not sure whether I understand this hack. Does this mean that I have to restrict myself to using the command line when launching programs for this to have any effect? The way I understand it only processes launched from a terminal session are affected by this. E.g. if I launch a program by clicking on a desktop icon it will not become part of a process group.
Be sure to get a refund if the article is not to your high standards.
Where do I put this on my Android phone to make Angry Birds run faster?
http://www.youtube.com/watch?v=h9mioHO4hoM
if you are not satisfied, we will send you the extra bash lines for free.
When I used to be the admin on the Mandrake User's Board, now http://mandrivausers.org/ , we adopted a number of policies governing user "politeness" and "helpfulness" with a focus on new users. It was a huge success and we had a large number of newbies! I mention all of this with a sense of nostalgia but also to show that not all Linux Forums are a bunch of jerks on a power/ego trip. Of course, it helped that I was out of work at the time and it was Spring :) Here's a shout out to the moderators and other admin's on the board! To Paul, Mystified, Spiny, Scoopy, Tyme and all other hard working Mods! Love Cannonfodder..
Have you fscked your local propeller head today?
WTF is systemd?
All of the above was encrypted with a Quad ROT-13 method. Unauthorized decryption is in violation of the DMCA.
So then why is your UID so high?
I will get off your lawn now.
If I compare the things Linus has done with what Poettering has done I think I know whose ideas I trust more.
Poettering seems to find things which are a mess and say "THIS looks like a job for SUPERMAN!!!!!!11" Since he's so brilliant and all, his design (done without consulting much with lesser mortals ) must be right, and if it breaks everything in the world and brings lots of design criticisms, well, the rest of the world and the critics (i.e. the morons) are what need fixing. Pulse was a disaster for years.
Favorite Poettering quote from this discussion: "Well, that nightmare already exists. It's systemd." Nightmare indeed.
Oh. My. God.
I only have 640KB! Like Gates said!
These bastards must be stopped!
Jesus fucking Christ!
Help!
switches the cgroup of each ${SHELL} to it's own group, making all command run from it in the same group as the terminal. Spawn a new term, and get a new cgroup.
All of the above was encrypted with a Quad ROT-13 method. Unauthorized decryption is in violation of the DMCA.
umm nobody reads your comment as it's protected by DMCA so don't expect an answ... oh sh... so if you made any question, don't expect an answer. I didn't read it, rly.
I don't know why people pretend that these two approaches are incompatible.
Users that compile their own kernel or distros that don't want to provide their own userspace solution get a good default.
Users or distros that want to use a userspace solution will disable that KCONFIG option and use their own method for grouping processes.
yah, that's old, that shell is from the late 70s. I mean, I used to use shells invented from the same time frame (vms dcl and nos), but I stopped using those in the early 90s.
Without bothering to read, if you set up the .bshrc option, and your distro later patches the kernel, will they interact badly? Why not both?
Some might see this as a smack in the face to Linus, but I say this is what open source is all about. Someone has a good idea, and someone else takes the idea and improves it. Bravo.
One never knows when one might need a rotten tomato... - King's Quest IV: Heir Today, Gone Tomorrow
I was busy - working.
It must have been something you assimilated. . . .
don't reply to signatures
don't feed the trolls
don't post flamebait
don't violate sacred memes
Racing stripes do the same thing and are much prettier.
I find magnets work best of all.
Only if they are pretty magnets, like Power Puff Girl magnets. Pretty counts!
Home of The Suki Series
Every grot knows da red onez go fasta!
The road to tyranny has always been paved with claims of necessity.
An early comment on LWN captured the technical argument best, I think, which I guess illustrates both the quality of the articles and posters on LWN. The background to this is we are discussing CPU scheduling. If you don't know what CPU scheduling is, think of it as form of mind reading. I'll illustrate.
Lets say you have asked your computer to do several things, in fact so many that if it follows the usual method of simply dividing its time equally between them it is going to annoy you. The video you watching might start flickering, or the music you are listening will drop out. So obviously the computer must now give more CPU time to playing your movie and less to whatever background task you started, such as that MP3 transcode of your 20,000 song library. Except how is the computer is supposed to know this? This is how we get to mind reading.
The hack we are discussing is essentially the discovery of a way to read the minds of one particular type of computer user - the Linux Kernel developer. The Linux Kernel developer is in the habit of starting huge background jobs called kernel compiles. These kernel compiles take a looong while, so the kernel developers, being very clever people, have invented all sorts of ways of speeding them up. One of those ways is to divide the task into lots of little bits, and then fire off separate tasks to do each. This takes maximum advantage of available CPU cores, soaking up every skerrick of available CPU time. This naturally enough leaves none left over for other important tasks like watching a movie while waiting your kernel compile. In this particular case the default CPU scheduling strategy of giving each task an equal share of CPU is woefully poor, because there might be 20 kernel compile tasks and just one movie watching task, so the movie player ends up with 1/20 of the available CPU time. This isn't enough to play a movie.
The mind reading trick discovered boils down to this: Linux Kernel developers use the linux command line interface to fire off the kernel compile. And it turns out that for years now the kernel has been able group the tasks started from a command line and give that group a single portion of CPU time, as opposed to a equal portion to each task in the group. Thus you only have to split up the CPU time into 2, one portion going to the kernel compiler group and the other going to the movie player. Naturally enough the movie player works real well with a 50% allocation of CPU, and so we have a happy kernel developer.
Now we come to the merits of the two hacks. They both do the job I just described equally well. The difference between them is that one, the kernel patch, is automagic, meaning it happens automatically without anybody having to lift a finger. But it comes at the expense of bloating linux kernel a tiny bit, even for users who won't benefit from it. The other way currently has to be done applied manually using a process the vast majority of Linux users will at best find difficult, tedious and error prone.
Seems like a simple decision eh - lets take the tiny bloat hit and not inflict our long suffering desktop users with yet another Linux user-unfriendly idiosyncrasy. But here is the rub: it doesn't help them. In fact, for some it might have a negative impact (a gstreamer pipeline started from the command line strings to mind). The people who will benefit from this are the ones that use the command line heavily and regularly. People like Linus. Which is why he liked it so much I guess. But these are precisely the people who will have no absolutely no trouble doing it the manual way.
Nicely done 'hack'. Those results are surprising, but not entirely unexpected: 200 lines
Torvalds should consider himself severely 'owned' on this. 200 lines in the kernel for something nobody will likely find any benefit in is crazy.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
Hey All,
Does anyone remember BeOS? I remember installing and playing with it myself back in the day...One of the great things about it was that you could spwn a ton of heavy process like movies and sound, etc. and everything would still be responsive...dis they do that in a similar way or was they underlying architecture just so radically different?
- Munky
WTF is systemd?
Let me Google that for you.
If you use Linux, you'll be using it soon.
Here are some slides explaining it.
Also, mods, the GP wasn't flamebait, it was a valid opinion.
I don't know why people pretend that these two approaches are incompatible.
No one's saying they are incompatible, and in practice distros will do just what you suggest. The LKML thread is more of a theoretical argument about what constitutes the "right" way to do something by default. I happen to agree with Lennart.
I don't see a kernel patch as the natural fit here, but I'm nobody compared to the fellows arguing the point, so I'll just take my improved desktop performance however it gets to me.
This is yet one more sterile pursuit from the 'Linux-has-to-perform-well-on-the-desktop' dept.
Computer science, people, think computer science. If you want smooth scroll, go play Super Mario.
If you use Linux, you'll be using it soon.
We'll see about that.
If the code quality follows the same curve as Pulseaudio, it will be a long while before I switch to systemd. Even if it means dumping Fedora.
Finally! A year of moderation! Ready for 2019?
No problems, and apparently, no downside. The netbook is visibly faster, even the spinning cube desktop switching animation spins faster.
Though if there's a problem with running both the hack and the kernel patch at the same time, I hope the word gets around when the kernel with the patch goes into distros.
Tech Public Policy stuff
You were mod'ed "funny", but seriously, I've been using tcsh (interactively) since the 80s and prefer it to bash.
I used tcsh back in the day before bash existed, as it was the only shell that had command line editing. However I hated its syntax.
And as soon as bash came out, I dropped tcsh like a hot potato.
I was busy - working.
Get a place where you don't have your back towards the door...
User: "it says please insert CD now, what should I do?"
Me: "hmmmm... did you already try inserting the CD?"
User: "o, never thought about that one, thanks"
Indeed, most users are so accustomed to Window's meaningless error messages that they won't even try to make sense of them.
Now, eventually these users who don't read error messages become developers... and guess what: their programs won't display meaningful messages because "nobody ever reads them anyways", even if it is a program intended for Linux. And the next generation says "why bother reading messages, they're meaningless anyways, I'll just quickly snap a picture of them so I won't even have to pollute my eyes with this meaningless driver, and send it to the helldesk"
I am TheRaven on Soylent News
...with commands you don't understand. Applications that want RT priority are incompatible with this shell scripting, so if you are doing anything RT you'll have to launch them with an alternate bash rc file that doesn't try to group the process
I can't say if its the placebo effect, but just about every part of my desktop experience now feels noticeably snappier, in UI response times across the entire desktop... (i used the script instructions, not the kernel patch.)
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.
To which Linux replied: "we've had this policy setting for a while now, no userspace mechanism has started to handle this". Basically, there are two arguments for inclusion: 1) systemd is too little, too late 2) autogroup scheduling does not prevent systemd from doing its own, more advanced/targeted cgroup scheduling.
Users would be better served by Lennart's approach, I think.
Yes. But the only users that benefit, are the ones that don't use the start menu of their WM: to benefit from this, you need a separate tty for each program, or in X terminology: start an XTerm, run your program from the command line; start a second XTerm, run your second program from that command line. Programs started from the GUI menu don't have a controlling tty, so they will not be affected by the current heuristic.
What I'm curious about:
Does one not need to install cgroup-bin in Ubuntu to make 'it' happen??
To me, this would be a logical prerequisite.
Can any expert confirm or refute this, please?
If you use Linux, you'll be using it soon.
We'll see about that.
If the code quality follows the same curve as Pulseaudio, it will be a long while before I switch to systemd. Even if it means dumping Fedora.
Fair enough. Perhaps I should have said "If you use one of the major desktop Linux distros and don't immediately rip out the init system when you perform a fresh install, you'll be using it soon."
On the topic of PulseAudio, I'd be a fool to pretend that adoption by the distros has been trouble free - and you'd be a fool to confuse the rocky rollout of a major new codebase with "poor code quality".
Hopefully some lessons have been learned and we won't see systemd pushed out before it's ready.
Lennart is being himself...
Yep. He strikes me as a guy who has grown so used to being crapped on by people without his level of domain knowledge that he approaches everything as a war, even when dealing with his peers. He's a "fix the architecture" kind of guy in a "patch it up" world.
The botched Pulse rollout by a few of the major distros didn't help his stock in a lot of peoples' eyes, but that doesn't make him any less right when he's right.
...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...
Won't stop the herd from picking sides or making wild claims about huge increases in usability. Go go gadget placebo!
It was poor code quality. It took 2 years to get the bugs to a bearable level. Not that it's bug free now, see Pulseaudio bugs in Fedora.
And Lennart Poettering is following the exact same pattern on the Fedora mailing lists as always.
Finally! A year of moderation! Ready for 2019?
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.
It would be a major "hack". First of all there isn't a single shell. There are many different shells, including ksh, csh, ash, sh, bash, and many others. Also, there is Busybox for embedded systems, and I'm sure there are others. There are also more than 1000 distributions. There is no good argument for expecting every shell dev or distribution channel to implement a change that can simply be done right in the kernel.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Does this go doubly if "x" is actually, y'know, X?
Xgl, Wayland... Yup, seems to work there. See also OSS, ALSA, the various sound daemons that exist in Linux-land (meanwhile, FreeBSD has had working multichannel audio or years in a way that's entirely compatible with apps written in the '90s).
I am TheRaven on Soylent News
And cynical...
Welcome to the club :)
Deleted
Obviously the short form omits at least one step, since cgroup isn't present in /sys/fs by default in Fedora. And even as root you can't create the directory, you need to enable cgroup (it is in the config file, but not active by default). You can waste a lot of time with google and wiki looking for how to enable this, but at that point I applied the patch and rebuilt the kernel. Can't say I noticed much difference, but with four cores, 12GB RAM and running off SSD the system is fairly responsive anyway.
Needs more detail for the average user.
One can come up with an infinite number of scenarios where Linux performance can be boosted by ad hoc hacks. It is ill advised. The kernel needs to be simplified not crammed with gratuitous hacks. Better to collect them in user space.
an ill wind that blows no good