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."

Comments

which one is 'right'?

[vikisonline]

There is a right way to do things and a hackish way. I wonder which one is which

Re:which one is 'right'?

[h4rr4r]

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

Re:which one is 'right'?

[spun]

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.

Re:which one is 'right'?

[Carewolf]

I think my computer just reached a load of 100.3

Browsing slashdot just fine. Back to watching fullscreen youtube videos... for science, of course!

Re:which one is 'right'?

[tepples]

You tell me which is best.

Best would be if the operating system distributor (Canonical, Red Hat, etc.) were to include the one that doesn't require a kernel patch in the next version of the operating system.

Re:which one is 'right'?

[gilesjuk]

Probably the Red Hat one, after all they probably know more about which values and settings to tune up than anyone.

They probably have a lot more of these, but it's a competitive business and they'll keep them secret to have an advantage over the competition.

Re:which one is 'right'?

[ehrichweiss]

replace "/sys/fs" with "/dev" as is mentioned in the "how to do this on Ubuntu" and it'll work just fine.

Re:which one is 'right'?

[clockwise_music]

Best for you right now? Update your .bashrc file.

Best for all the people who miss this little nugget? Include it in the kernel.

Re:which one is 'right'?

[mug funky]

umm... open source?

Re:which one is 'right'?

[deek]

I didn't even bother using /dev. I just created a directory /cgroup, and mounted the virtual filesystem onto that. It seemed more logical to me. I like to keep /dev free of non-device files.

Re:which one is 'right'?

[WingCmdr]

There is a right way to do things and a hackish way. I wonder which one is which

You left out the third alternative. There's the LINUX way to do things.

Re:which one is 'right'?

[bemymonkey]

And more importantly, will either one do anything for Android? :p

Re:which one is 'right'?

[arivanov]

Neither.

As I said in my post to the previous article on Slashdot on this it should be the window manager's job to do this and it should be based on which process talks to which. No terminal should be involved.

Both of the suggested approaches - the shell hack and the linux kernel patch are nerd material. They work only for stuff that has controlling terminal (kernel patch) or for stuff that is launched from the terminal (bash hack), not for stuff you launch directly from the desktop environment.

The 5 lines worth of bash need to be rewritten into 10 lines of python for KDE or a couple of pages of C for the gnomish abominations. With proper permissions of course- I see some chmod 777 there which generally makes me start looking for an axe and a neck to apply to. Then it will be the "right patch". Another alternative is to add this to the PM system - the KDE power daemon or the gnome alternative. It will be right in place there as it will have access to current power and performance preferences. For example - if I am watching a video or presenting I want that in a separate process group from the rest of the crap that is being done in the background.

Re:which one is 'right'?

[business_kid]

I think this is missing the point. A patch is a patch, and a tweak is a tweak. Which one is moot. The point to me is, here was this functionality for years lying latent in the kernel, as people put up with inferior performance. As soon as the idea is discovered, more than one way of doing it is noticed. Can we have more of these life-changing performance improvements, please, and how? What other potential is tethered by sub optimal performance.

Re:which one is 'right'?

[antientropic]

Best for all the people who miss this little nugget? Include it in the kernel.

Or just include it in the system-wide bashrc. That doesn't seem particularly hard to me from a distro-maintainer point of view. And it seems preferable to hard-coding a scheduling policy choice in the kernel.

Re:which one is 'right'?

[TheRaven64]

The stock .bashrc on most Linux systems includes /etc/bashrc. On the recent systems I've looked at, this then includes /etc/bash.d/* (or something similar). You can get the same effect as adding this to every single user's .bashrc by simply dropping a file with the magic lines into /etc/bash.d/. A package can do this and you don't even need to reboot for it to take effect. Best, it's trivial to turn off for systems where it's not applicable.

So, which is a better approach?

Re:which one is 'right'?

[marcosdumay]

Better yet if they include a "Desktop-configs" package that sets that behaviour (and whatever else they think is better for a desktop), so they can let the servers untouched. Doing something like that on the kernel would be the definition of non-clean.

Re:which one is 'right'?

[compro01]

Open source is not a panacea. It's perfectly possible to hide optimized settings in plain sight, though then it's not so much "secret" as "not advertised".

Re:which one is 'right'?

[mcgrew]

Every distro of Linux I've tried has "worked correctly out of the box" (Except Red Hat, and the last time I tried Red Hat was ten years ago).

And Windows hardly "works correctly out of the box" if you're installing Windows on a blank hard drive (which, seeing as how you're not a nerd, you've never done). A Windows install takes hours with multiple reboots, after which you have to install any and all applications you want to use, then tweak the damned thing to make it useable for you.

With modern Linux distros, there's about a half hour of clicking "yes" and "no" and your computer is set up with all the apps you need, ready to go.

Tell me, WTF are you doing at slashdot? Did you even read the masthead?

Re:which one is 'right'?

[ookaze]

Best for you right now? Update your .bashrc file.

Best for all the people who miss this little nugget? Include it in the kernel.

This is nonsense.
Best for all people who miss this little nugget? Include it in the Linux distributions.
This is what they are for BTW.

Any linux kernel?

[w0mprat]

Will this work on more than just x86, for example a rooted Android phone? I might try this now.

Re:Any linux kernel?

[Anonymous Coward]

Yes, because is has to do with the way the kernel handles multitasking.

Re:Any linux kernel?

[willy_me]

But I was under the impression that Android devices already utilized a different scheduler. In addition, phones have different requirements - for example, some might require a real-time kernel in order to operate on a cell network. Long story short, messing with the scheduler could have serious repercussions on an Android device. Only those who really know what they are doing should attempt it. The rest of us should simply wait - unless you don't care if your phone is reliable or not.

Re:Any linux kernel?

[NuShrike]

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.

Re:Any linux kernel?

[GooberToo]

Process groups must be in the kernel. If the required kernel support is not compiled in (most use a monolithic kernel) then it won't work. IIRC, some ROMs (Cyanogen perhaps) do include such support.

How does this work?

[Manip]

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.

Re:How does this work?

[MichaelSmith]

Looks like an alternative solution is already there in the Kernel. The commands just switch it on.

Re:How does this work?

[greg1104]

It makes every process spawned by the user that passes through the bash shell add their process ID to a per-user task control group. See the documentation on control groups for more information about exactly what that means, and what what some of the commands involved aim to do. I'm not sure if this is exactly the same impact as the kernel-level patch, which aimed at per-TTY control groups. That might includes some processes that don't pass through something that executes the .bashrc file along the way.

Re:How does this work?

[MBCook]

The kernel has a mechanism to schedule groups of processes, and it has for years. By grouping tasks together, you can make one process (video playing) get the same cpu share as a group of processes put together (compiling code). By doing this (instead of the video processing being equal to just one of the compiling processes), everything feels more interactive, even though it's actually slightly slower.

No one uses scheduling groups because they have to be setup by root and it's not the easiest thing in the world (you have to write stuff into sysfs, I think). No distributions set them up.

The magic kernel patch just adds a simple rule to the scheduler. When a process starts, it goes into a group with the rest of the processes in that TTY (virtual terminal). This means the user doesn't have to do anything and the groups are setup automatically.

Poettering thinks this is somewhat hackish, and that things shouldn't be based on what TTY a process is started on. He made the little script to prove that this can easily be done in userspace.

Linus has rejected this, basically saying that we've had years for people to make something like this and no one did until the kernel patch came along. The patch is simple, reasonable, and doesn't require distributors to ship updated userland files to put processes in groups.

I should note that my understanding comes from LWN, which has had excellent coverage of this on their kernel page, as always. You'll be able to see their articles in two weeks if you're not a member (which is worth it if you like this kind of stuff).

Re:How does this work?

[blair1q]

So you could have got the exact same performance improvement in this test by doing

"nice make -j64 whatever"

and making the make program and all its little boggies stay out of the way of your X server...

Re:How does this work?

[Timmmm]

So if you only use GUI apps, it has no effect at all?

Re:How does this work?

[Corbet]

Thanks for the nice words about LWN! Here's a special link to the LWN article on per-tty group scheduling for Slashdot folks. Hopefully a few of you will like what you see and decide to subscribe.

Re:How does this work?

[BlackPignouf]

Thanks for the explanation.

Does it have any impact if you only have 1 CPU? If you only launch apps from Gnome/KDE?
Would it help to use GNU screen?

Re:How does this work?

[sjames]

Gooooooood make -j64 whatever.

Roll over!

People come up with the oddest names for their pets sometimes.

Re:How does this work?

[hitmark]

if set up right, daemons and such would be in a different process group.

Re:How does this work?

[nitehawk214]

Thanks for the nice words about LWN! Here's a special link to the LWN article on per-tty group scheduling for Slashdot folks. Hopefully a few of you will like what you see and decide to subscribe.

You've got a per-tty mouth.

Re:How does this work?

[maztuhblastah]

The patch is simple, reasonable, and doesn't require distributors to ship updated userland files to put processes in groups.

It also doesn't do a good god damn for the average desktop user. Sure, if your benchmark is a massively-parallel kernel build it works great. But if -- oh, I don't know -- you launch most of your X apps via your DE's menu, guess what? They'll all be grouped together and the patch will do bugger-all for you.

So it's 200+ lines of code to help a subset of developers... who are basically the only people who used the existing control group stuff in the first place.

*sigh* Why is it that the scheduler is always such a facepalm-evoking area of the kernel?

Re:How does this work?

[GooberToo]

So you could have got the exact same performance improvement in this test by doing

"nice make -j64 whatever"

No!

That would lower the priority but you would still have 64 jobs, plus everything else that was already running, all receiving their equal share of scheduling; well, these with a lessor priority. That's not the same thing as what the patch/scripts do.

Re:How does this work?

[monkyyy]

>*sigh* Why is it that the scheduler is always such a facepalm-evoking area of the kernel?

cause it either has to be insanely tedious or ineffective

Re:How does this work?

[master_p]

From what I understand so far, process grouping is a mechanism that allows better load balancing between I/O tasks and interactive tasks. Am I correct so far?

Well, it surprises me that an interactive task is not considered an I/O task. Take a video player, for example: doesn't it send video frames to the the video card? it's primarily an I/O task.

Here is another example: browser scrolling. When a browser view is scrolled, a huge amount of data are sent to the video card. So this is also an I/O task.

So both 'classic' I/O (disk operations like compiling) and video/audio I/O are actually the same thing, i.e. moving large blocks of data around.

Then, shouldn't the correct approach be an algorithm that prioritizes I/O based on intended usage? the display I/O should get a higher I/O priority on desktop systems than disk I/O or network I/O tasks, and vice-versa on servers.

Re:How does this work?

[blair1q]

They'd be tossed into a lower-priority queue. Every time my higher-priority process wanted the CPU, it would get it. The only time those lower-priority processes would get the CPU is when my process didn't want it. It wouldn't matter how many of those there are, because I don't have to wait in line behind all of them, I just have to wait until the one currently using the CPU pends.

That's what priority was invented for. This thing about group scheduling looks like a combination of time-slicing built on top of a single-priority queue. But since the problem is that things don't seem to operate smoothly it's a priority problem, not a synchronization problem, so time-slicing is the wrong solution and prioritization is the right solution.

Re:How does this work?

[GooberToo]

That's not how it works. The scheduler specifically prevents starvation; as should be. Which means you still wind up with 64 jobs all making a grab for CPU, albeit much less frequently, which is more than likely to saturate the limited number of available CPUs for "bursty peaks". Which surprisingly enough, is exactly what you get.

Now what you're saying would be accurate if we were talking a round robin scheduler. But that's not what most of the world uses on their desktop.

What's the catch?

[TheGoodNamesWereGone]

Is there a catch?

Re:What's the catch?

[Meshach]

Is there a catch?

Yes. To quote Linus:

User-level configuration for something that should just work is annoying. We can do better.

I think I will use an actual kernel patch rather then this hack in user space.

Re:What's the catch?

[Monkeedude1212]

I didn't see any Try's, so I don't think so.

Re:What's the catch?

[Lemming Mark]

This isn't a nasty hack like some userspace bodges round kernel problems can be. The functionality to schedule the CPU in controlled ways to different groups of processes has been in the kernel for some time now and simply needs configuring from userspace. The 200 line patch adds some default configuration of this mechanism to the kernel; this alternative uses the existing functionality to do the same thing. The same kernel mechanism should end up handling it.

It's good if the kernel can do more stuff so that the user doesn't have to - where it makes sense. But this is actually a reasonably neat solution if you want the same behaviour without upgrading your kernel.

Re:What's the catch?

[c 0xFF]

That's easy. Do or do not, there is no try.

Re:What's the catch?

[blair1q]

It wouldn't be a hack in user space if it were built into the shell.

It seems to be creating a file in a group registry that tells the kernel that your shell, which is interactive, is a group. What that means I don't know, but I'm sure it's something that can be built right into the shell, which can manage that for you. The code that does something useful with a group once it's identified is clearly already part of the kernel, and runs better than the kernel hack that's proposed.

Building it into the shell means that (a) you don't have to build it into your shell configuration scripts, where it can easily be omitted and the fu lost forever for users who lose fu; and (b) you can better handle situations where the shell and its children get killed.

Re:What's the catch?

[blair1q]

You can only put a try on the 22nd catch.

Re:What's the catch?

[Monkeedude1212]

So the 22nd catch is the exception?

Re:What's the catch?

[weirdcrashingnoises]

I tried that it didn't catch on...

Re:What's the catch?

[segedunum]

Indeed. Lennart has a history of naff userspace stuff that should be handled by default in the kernel with PulseAudio.

Re:What's the catch?

[Cougar Town]

There's an exception to every rule.

Re:What's the catch?

[JustOK]

that's not always true.

Re:What's the catch?

[zr-rifle]

Seems a Major Major bug to me.

Re:What's the catch?

[zm]

finally, a comment that makes sense.

Re:What's the catch?

[ZaphDingbat]

Except that either the kernel patch or the .bashrc hack (and possibly a better version of that hack) will eventually be the default in your distro's setup. *Either way*, you won't care how it gets to you. It sounds like the .bashrc hack or other, similar tricks have the advantage of (a) working now, with current kernels, and (b) letting the distros decide the heuristics of grouping processes, instead of the kernel.

Re:What's the catch?

[VGPowerlord]

I tried that, but when I did, it just bombed instead. Apparently, despite it only working if you try the 22nd catch, trying the 22nd catch makes it fail!

Re:What's the catch?

[bluefoxlucid]

I've been trying to move LWN to userspace for years.

Re:What's the catch?

[blair1q]

Take a look at the code for one sometime.

See all those #ifdefs?

Probably not, since you have your head shoved so far up your ass.

Ah the beauty of the interconnected world...

[Anonymous Coward]

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 ^^

Re:Ah the beauty of the interconnected world...

[Anonymous Coward]

Not really, no. The solution Lennart proposes works in tandem with systemd, which is yet another init replacement that's not being used by anyone at the moment. It is speculated that Fedora 15 will start using it, being that Lennart works for RedHat and all, but I frankly don't see it gaining traction anytime soon outside of RH.

So, a userspace solution that relies on a piece of software that no one uses (and, the cherry on top is that systemd will render a system unbootable if the kernel isn't compiled with CGROUPS, that ought to end well, really, what could possible go wrong with it), pitted against an in-kernel solution that is completely transparent to the user. Guess which is going to win.

Re:Ah the beauty of the interconnected world...

[MichaelSmith]

Yeah whats the point arguing about the nature of god if some smartass just gives you his phone number.

Re:Ah the beauty of the interconnected world...

[ichthyoboy]

Considering that Lennart wrote the steaming, broken pile known as PulseAudio, his solution makes perfect sense...

Re:Ah the beauty of the interconnected world...

[shish]

the steaming, broken pile known as PulseAudio

That was the case a couple of years ago, but have you tried it recently? I haven't actually had a single audio problem since switching from debian/alsa to ubuntu 10.04/PA, and I now have a ton of useful features on top :-) (per-app volume, per-app output devices, network streaming, seamless switching between headphones and HDMI, etc)

Re:Ah the beauty of the interconnected world...

[ichthyoboy]

Honestly, no. I was so turned off by the problems associated with it when it was first introduced to Ubuntu a few years back that I ripped it out and never looked back, and when I moved to Arch I didn't even consider it. It's kinda like the associations people make with certain kinds of alcohol after a bad hangover: even a look will make them nauseated.

Re:Ah the beauty of the interconnected world...

[segedunum]

Stuff in userspace tends to go wrong. If you can handle a pre-requisite in the kernel then do so. /dev/dsp is still the only interface in the kernel that tells you to get lost if it has been locked. Imagine if other kernel interfaces could only do one thing at a time. That's the only reason for Pulse being in existence - mixing. I'm telling you, Linus would accept a patch for in-kernel mixing tomorrow because it makes sense.

As for the rest, there are still a list of bugs as long as your arm regarding peculiar cases that will never get fixed, but they might if we wait long enough. Why you would want network streaming in such a system before you get local sound output right is beyond me, but that seems to be Lennart. He's stuck patches into Pulse in the past that don't actually do anything and blamed kernels for performance issues.

Re:Ah the beauty of the interconnected world...

[segedunum]

Oh, and he steadfastly doesn't think that audio is a unversal system service........ Nuts.

Re:Ah the beauty of the interconnected world...

[swillden]

I'm telling you, Linus would accept a patch for in-kernel mixing tomorrow because it makes sense.

He would? After consistently rejecting many such patches for years, because audio mixing isn't something a kernel should do? When did he change his mind? And why?

Re:Ah the beauty of the interconnected world...

[MarkRose]

And it was included in Ubuntu before he said it was ready, too. You can't fault him if distros decide to include alpha/beta software.

Re:Ah the beauty of the interconnected world...

[DeVilla]

I for one have never had pulse work well on a system. My latest is Ubuntu Studio 10.4. Before I removed pulse, I would run a game like X2. The in-game sound would stutter, crackle and distort until sound was killed for the process and I was left with silence. It was awful if I ran Rhythmbox and a game like Lugaru at the same time. It just didn't work for anything in games. It really didn't too great for just Rhythmbox alone either. If you start jackd for studio work, you lose all of your non-jack based sound.

Since I don't have Bluetooth or any of the requirements that justify pulse, I'm better off without it. I get sound that just works (as it had for me for years prior to pulse) and it takes advantage of my multi-open sound card (something the pulse developers don't intend to support). That last part means I don't get the CPU load that pulse generated with software mixing. To me, not supporting multi-open hardware is like Xorg saying they won't support any hardware accelerated 3D.

I just wish it didn't keep getting harder to prevent pulse from running.

old-school

[MagicM]

I heard that if you stick a penny to the top of your case it speeds up everything by 200%.

Re:old-school

[Suki I]

I heard that if you stick a penny to the top of your case it speeds up everything by 200%.

Racing stripes do the same thing and are much prettier.

Re:old-school

[blair1q]

They don't make the kind of tape that makes that work any more.

Re:old-school

[the_fat_kid]

Two words:

Speed Holes.

Re:old-school

[BlitzTech]

Pff. You can't just pretty up the outside and expect the insides to work better, n00b. You have to wax your CPU (and modem) to make them slick - decreases friction to make your computer run faster! Also, I heard putting graphite lubricant on your RAM works wonders, but I haven't tried this myself.

Re:old-school

[MidoriKid]

Penny'll start a fire.

While the bashrc approach may seem attractive

[joeflies]

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.

Re:While the bashrc approach may seem attractive

[Trepidity]

True, though it could be done at the distro level, which appears to be the author's plans (the person who wrote this script works for Red Hat, and discussed elsewhere in the thread what Red Hat's plans are for rolling out systemd, which will handle this). Then things would be appropriately updated by the maintainers rather than relying on users to keep their .bashrc synced with infrastructure changes.

Re:While the bashrc approach may seem attractive

[Shimbo]

True, though it could be done at the distro level, which appears to be the author's plans (the person who wrote this script works for Red Hat, and discussed elsewhere in the thread what Red Hat's plans are for rolling out systemd, which will handle this).

Indeed. "Should we be punting this for userspace tools to handle?" isn't the same question as "should we punt it to the user?".

Re:While the bashrc approach may seem attractive

[kaaona]

(the person who wrote this script works for Red Hat...)

... this approach doesn't work at all with RHEL5.5 Server. Even the root user is not allowed to mkdir in /sys/fs:

[root@lion] /sys/fs
# mkdir cgroup
mkdir: cannot create directory `cgroup': Operation not permitted

Frankly I was a bit surprised by this response. Perhaps it's an old kernel thing. After all, RHEL5 is just Fedora 6 dressed in a tuxedo.

Re:While the bashrc approach may seem attractive

[Psychotria]

True, though it could be done at the distro level, which appears to be the author's plans (the person who wrote this script works for Red Hat, and discussed elsewhere in the thread what Red Hat's plans are for rolling out systemd, which will handle this). Then things would be appropriately updated by the maintainers rather than relying on users to keep their .bashrc synced with infrastructure changes.

I understand what you're saying and agree. The problem I have is with your userid. 597. Users with IDs as low as this are mythical. Kind of like unicorns or maybe even grues; they are creatures of the imagination. Users with sub-1000 user ids are DANGEROUS. They say stuff that most often makes sense and this can be mesmerising. They do this to lure us into the trees to have intercourse with sirens of the forest, I have heard. Your post is an incredible example of the delirium that can ensue when magical beings make posts. Your post also contains NO REFERENCE TO MICROSOFT. This is indeed disturbing and should set alarm bells ringing. I would not be surprised to be able to type "open letterbox" in your post and see an envelope containing a letter or note.

Re:While the bashrc approach may seem attractive

[Psychotria]

Oh, and that Cornelius fellow or whatever he calls himself better not respond to my post. He is obviously a siren luring people into his tree before sucking their life out of them as part of some kind of sexual feeding that saps the life out of people like a bug saps, ummm, sap.

Re:While the bashrc approach may seem attractive

[gl4ss]

the distro builder is also an user.

Re:While the bashrc approach may seem attractive

[jemtallon]

Looks like the patch only works if the OS has cgroup support, which was added in RHEL6. So for those of us who are using older distros, a kernel patch is the only fix.

Re:While the bashrc approach may seem attractive

[awshidahak]

The even weirder thing is that they've been around that long, and are still around. Weird. Probably a plot from Microsoft. Or some jobsian walled garden. But we shouldn't worry too much about them so long as we have Firefox with no-script running on linux.

Seems like a good plan

[Lemming Mark]

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.

Re:Seems like a good plan

[cynyr]

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:Seems like a good plan

[ArsenneLupin]

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?

Exactly. Gui apps (usually) don't have a controlling terminal, so would all end up in the same scheduling group, making the patch ineffective.

However, with user-space managed cgroups, the window manager (or whatever starts up the GUI apps) could do its own thing (the .bashrc hack doesn't work as is either, because the window manager doesn't usually invoke apps via the shell)

4 Lines Is Not All. Let's Not Forget...

[mgmartin]

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.

Poettering is pimping systemd

[Anonymous Coward]

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:Poettering is pimping systemd

[Chuck Chunder]

so those of you who've experienced broken sound in recent years

In recent years?

Has Linux ever had a stable sound system?
My recollection is a neverending series of different sound related components (OSS, ALSA, ESD, aRts, Jack etc) of which the best you could say is that they worked most of the time but invariably didn't behave very well in certain cases.

Lennart seems to cop a lot of crap over Pulseaudio but as far as I can tell it's a positive contribution in an area with a lot of historical and legacy issues.

Re:Poettering is pimping systemd

[h4rr4r]

It really is, and if things like flash played nice with the rest of the system it would be far less of an issue. No, grabbing /dev/audio is not the right way to play audio.

Re:Poettering is pimping systemd

[Provocateur]

so those of you who've experienced broken sound in recent years

In recent years?

The person you are replying to is from the future.. He was sent to warn us of the dangers of making the LHC operational, but he is forbidden to mention it directly lest he alter the future from whence he came.

It was foretold that we would recognize him when he speaks of a world where sound worked flawlessly in Linux.

Re:Poettering is pimping systemd

[cynyr]

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:Poettering is pimping systemd

[cynyr]

hmm, show me per app audio adjustment from a central control interface using ALSA. Not saying i like pulse, but that is the only feature that I'm at all interested in.

Re:Poettering is pimping systemd

[Peter Bortas]

Oh no, sound was working for a couple of years. ALSA had stabilized. Then came PulseAudio.

Re:Poettering is pimping systemd

[h4rr4r]

This is indeed a problem.

I currently do not face it as I do not use my desktop for much audio, and me and the girlfriend use fast user switching to share the machine as we only have one monitor in the office.

Either way the flash method of playing sound would break what you are trying to do as well.

Re:Poettering is pimping systemd

[Wonko the Sane]

You don't need Pulseaudio if your machine has a single set of speakers and a single input device or maybe a couple of devices that never change.

As soon as you add things like bluetooth or USB headsets into the mix and want to do things like move audio streams between output devices without stopping them (play the sound from the DVD I am watching on the main speakers, unless I turn on the bluetooth headset) you either need to modify each and every application to understand all these devices or else you need some kind of sound server.

Re:Poettering is pimping systemd

[Chuck Chunder]

Which couple of years? I bet typing 'ALSA' and those years in Google brings up a whole bunch of people struggling and esoteric how-tos.

Re:Poettering is pimping systemd

[godrik]

"Has Linux ever had a stable sound system?"

Yes, when it did not supported sound.

Re:Poettering is pimping systemd

[shutdown -p now]

No, grabbing /dev/audio is not the right way to play audio.

Funny how it is on FreeBSD, and things generally just work.

So much for Unix Way.

Re:Poettering is pimping systemd

[shutdown -p now]

ALSA is the next generation of OSS.

No, it isn't. ALSA is completely different (and many would claim, deficient) in both design and implementation to OSS.

Re:Poettering is pimping systemd

[drinkypoo]

supposedly it works fine on Linux with OSS4 too

Re:Poettering is pimping systemd

[m50d]

aRts actually worked, beautifully. So of course, it's the one thing on your list that's no longer maintained.

(Yes, I know that's not quite true, esd is similar).

Re:Poettering is pimping systemd

[segedunum]

Funny how it is on FreeBSD, and things generally just work.

Yer. FreeBSD continued to support OSS perfectly fine when a lot of Linux developers said that OSS was unsupportable and hasn't had any trouble at all, with Linux systems having to shoehorn tons of userspace crap to support mixing etc. and we've been through God knows how many over the past decade. I wish Linus took more of an interest in sound and called this out for what it is.

Re:Poettering is pimping systemd

[Peter Bortas]

I bet you would. But those were probably about some badly supported chipset, not trying to run packages from the default Ubuntu repository on an unmodified Ubuntu.

Because that's what happened. We went from "If the hardware is supported it works" to "It might work, and oh look! You can change volume individually on the apps without app-support!".

Re:Poettering is pimping systemd

[jedidiah]

Actually, having a single system control panel is very handy. There's one unified UI for everything and you don't have to go fishing inside the app.

Plus there's always the problem of whether or not each individual user wants the local volume control to change "global" or "local" volume. No matter how it is done, someone will wish it was done the other way.

Re:Poettering is pimping systemd

[wertarbyte]

I have a multi user OS, and i like using it that way.

Amen, brother. But we are hitting hard times; network-manager, those power-manager widgets in Gnome/KDE, Bluez, etc. all have one thing in common: for some reason, they assume that on one computer, there is a single user logged in, running a single desktop environment and probably can get root privileges. Come on, no network until X is up and somebody is logged in? No pairing with another Bluetooth device (other than through strange hacking) if you only have text console? Power-Management (which should be a system service) managed by a GUI app? I have nothing against graphical shells for those purposes, but the real work should be done by some kind of daemon, enforcing a system wide policy and accepting "suggestions" from user applications, with D-Bus there even is a thing that could accomplish that. But those freedesktop.org stuff is always extremely, well, desktop centric, enforcing a single user policy wherever I meet it. Scary.

Re:Poettering is pimping systemd

[Thumper_SVX]

"Has Linux ever had a stable sound system?"

Yes, when it did not supported sound.

Indeed... I distinctly remember Linux working just as well with my Soundblaster AWE32 as it did with my Gravis Ultrasound I had before it...

Whee...

[Target Practice]

Man, after reading some of that thread, those folks in kernel development make Slashdot users seem downright well-mannered.

Re:Whee...

[Pharmboy]

You want to see some real, over-the-top rudeness? Go to a forum designed to help Linux newbs.

I've been tooling with Linux for 15 years now, so used to the arrogant "help" found in many forums and groups, but I've had non-Linux friends check some out and were completely amazed at the average level of rudeness in the average "help" reply. It certainly didn't make them want to jump into Linux when that is the average help. For obvious reasons, half the admin-types on Linux forums remind me of the comic book guy in the Simpsons.

Yes, people should know more about the OS, but sometimes they just want to get something to work. Being reminded that "This isn't Windows" and "you should know $x" must feed some ego hunger. Granted, not all are like this. Only half.

Re:Whee...

[gandhi_2]

Ever seen a 50-year-old ER nurse? 90% of the time, they are callused to the suffering around them. It comes with repeated exposure to the environment, and although their demeanor may seem rough to others, they are extremely efficient and skilled.

Sometimes, I think what some mistake for IT snobbishness is just a natural consequence of exposure to the lifestyle.

I thought it would be fun to post some things in answers.yahoo.com in the IT-ish categories... after a while you realize that the REALLY good questions are drowned out by people who REALLY just need to GTFO and RTFSomething.

I work in public ed IT, and can say with NO uncertainty that most people don't want the right answers, they want the nice answers. It's hard not be rude in some cases.... it just comes out your pores after enough exposure to the environment.

Re:Whee...

[codepunk]

Yep you have got to put your big boy panties on before jumping into that.

Re:Whee...

[bmo]

I get rude when people expect Linux to be Windows after about the third time they complain about where the control panel is (among other things) and when they're simply trolling. It's amazing the amount of trolling going on in the help forums. Sometimes it extends to irc.

Car analogy follows:

"Gee, this BMW is nothing like my Ford." "Why is the battery in back again?" "They should put the battery in the engine compartment" ("but it's there for weight distribution") "I don't care about that, it's stupid"

It's not Windows. It's not a cheap Windows. It's not anything like Windows. Stop expecting it to be Windows. Once you do that, a lot of things become _much_ easier.

--
BMO

Re:Whee...

[__aagmrb7289]

And thus, the cycle perpetuates. Better yet, if you are going to be an ass in your reply - just don't reply. That means the user might NOT get help - and that may be a concern for them - but it's better than getting attacked - which will definitely be a concern for them.

Re:Whee...

[Knuckles]

I've been using Linux for 15 years too and I have never seen that. I don't know where you people go to have such bad experiences. OTOH, the Windows forums I sometimes stumble into via Google are usually full of clueless guys and devoid of actual help. Granted, Windows is opaque, but still.

Re:Whee...

[debrain]

Ever seen a 50-year-old ER nurse? 90% of the time, they are callused to the suffering around them. It comes with repeated exposure to the environment, and although their demeanor may seem rough to others, they are extremely efficient and skilled.

Sir –

I don't disagree with your point that repeated exposure to the environment makes one rough. I do have a different perspective on the effects of that.

In my experience most really good nurses quit because of the way they're treated by the condescension of doctors and entitlement of patients, as well as the toll of watching and caring about patients who suffer morbidity and death.

The nurses that stick it out are able to do so precisely because they don't care — about the way they're treated or how patents turn out. At the same time they aren't competent or ambitious enough to find something else to do that doesn't take such a toll.

Few calloused 50-year-old ER nurses are in it because they care. If they don't care, then you're an object to them.

There are of course exceptions, especially in e.g. teaching hospitals, but I suspect they're be very rare in the nursing industry.

Re:Whee...

[h4rr4r]

So you would rather have no help, instead of help that is not phrased to your liking?

Grow up.

Re:Whee...

[lymond01]

Better yet, if you are going to be an ass in your reply - just don't reply.

I learned this on the Everquest boards back in 1999. People read your post history and make judgements. Unless you want to be labeled a jerk with evidence proving you're a jerk, just be friendly or silent. Friends are way more useful than enemies.

Or you can be like Ender: if you're going to use violence, finish them off so they can't come back later with more troops.

Re:Whee...

[mezron]

I always just assume the totally over the top asshats are Microsoft employees doing that to keep the Linux users are elitist stereotype alive. Scare the n00bs back into the comfortable fold.

Re:Whee...

[h4rr4r]

I prefer to be friendly to the folks I like and not worry about the rest. I tend to be pretty easy going, and have helped my fair share of folks, including mailing other slashdotters hardware. I have zero problem showing people how to do something or where they can find more information on a topic.

Complaining about stuff you get for free just irks me, it is the ultimate rudeness.

Ever hear the expression "beggars can't be choosers"?

Re:Whee...

[mrmeval]

They actually have to be around people. If they were as rude as the anonymous cretins on some forums they'd slashed, beaten or killed.

Re:Whee...

[Pharmboy]

Ever seen a 50-year-old ER nurse?

You are right in that many people are inadvertently (or apathetically) rude for the purpose of efficiency. "I don't have time to be nice, I'm busy helping sick people, and being nice slows me down." While it makes them efficient and effective at the technical skills (things that CEOs love) it doesn't necessarily make them the best care givers. Outside of actual life and death emergencies (and your ER example would be excempted), how care is given is as important as the care itself, particularly with the very young and the very old, who might be reluctant to seek help in the future if they are always scolded when getting that very care.

Re:Whee...

[adisakp]

Ever seen a 50-year-old ER nurse? 90% of the time, they are callused to the suffering around them. It comes with repeated exposure to the environment

So the people who are good at Linux treat the noobs like shit because they calloused from all the pain they've suffered? That's hardly a ringing endorsement for Linux if using it long enough to become a proficient user makes you as shellshocked and numb as someone working in a triage unit.

Re:Whee...

[h4rr4r]

I believe he meant they were calloused from having to deal with new users not the OS.

Re:Whee...

[h4rr4r]

Take a deep breath Nancy, people are not always nice. Dealing with people who are not always nice is a skill you should develop. Being rude back only makes them be more mean to you.

Please in the future anytime you ask for help mention that you only want help that is friendly and not at all mean because you have sensitive feelings.

Re:Whee...

[horza]

I've found the opposite. Much of the small amount rudeness I've seen has mostly been deserved. People that can't be bothered to use Google, those that want free tech support that they wouldn't hesitate to drop $100 for if MS Windows, sometimes questions that have already been answered on the same forum.

On the other hand I have been amazed at the amount of free help I have been given from newb until today. I've never had anybody be rude, but that is because I treat other people's time as valuable as my own.

Phillip.

Re:Whee...

[the_womble]

I have used the forums for several Linux distros (Ubuntu, Mandriva and Mint) quite heavily, as well as occasionally reading other forums and I have rarely seen a rude reply, and never received one.

What forums are you talking about?

 

Re:Whee...

[zippthorne]

Pfft. Forum software doesn't index things in such a way that "using the forum search" is frequently useful for getting an answer to a question.

There's a difference between knowing that the answer is there, and being able to find it without actually knowing what the answer is.

And, anyway, if it really was answered, there's an even lazier option to being rude: put a link to the answer.

Re:Whee...

[zippthorne]

You're missing the point. Rude help doesn't merely annoy techies who "get over" the rudeness. It also scares away the newbies, thus reducing potential sources of future help.

Classy move there, BTW, telling someone to "Grow up" as if they're immature for noticing immaturity...

Re:Whee...

[hey!]

Ever seen a 50-year-old ER nurse? 90% of the time, they are callused to the suffering around them. It comes with repeated exposure to the environment, and although their demeanor may seem rough to others, they are extremely efficient and skilled.

Which only shows how much more *advanced* computer geeks are. We're rude from the time we hatch out of our *eggs*. And we're justified in not reacting to the suffering around us. We don't need to *react* because we *caused* it.

Re:Whee...

[Anonymous Coward]

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:Whee...

[Blakey Rat]

That's your defense? Seriously? That's, that's the best thing you got?

Re:Whee...

[vegiVamp]

This.

I'm on a few mailinglists, and while I do my best to provide clear, concise, correct and helpful answers to questions, I keep being amazed at how some people simply don't bother to do the basics first. Like, you know, even looking in the general direction of the manual.

One of the lists I'm most active on these days is the MySQL one, given that I'm almost fulltime DBAing these days. Note that MyQSL has excellent and comprehensive online manuals for every version you care to run.

I've seen people actually think that list is populated by MySQL employees who are paid to answer their every stupid question, and get impatient and testy if they haven't seen an answer in ten minutes.

i've seen people spam the list with first their inane RTFM questions, followed by a great big stream of "insights" on how he solved it and the most obvious straight-from-the-manual statements.

I've seen people who seem to think that the list is there to write their queries for them. After I got rather miffed and wrote a bit of a sharp mail at one of them about basic manners, what the list is for, how to ask questions properly and what to do before you even think of asking the list; that guy now consistently does his homework, tries to work it out for himself and if he really doesn't find it or wants another opinion, politely puts the question to the list in a clear and concise way. Of course he now gets all the help he needs, and he's even put a few quite interesting things to the list in the mean time. He has, interestingly, also taken to calling me 'Sir' whenever he asks me a question. I never asked for it, but I have to admit I kinda like it :-)

Sometimes it's necessary to make it quite clear to people what they can and cannot expect from online help, and how to behave there. This used to be perfectly acceptable, but since Eternal September began, the flood of ignorance has gotten so vast that I can fully imagine it can sometimes be hard to remember actually helping people in the middle of all the stupidity.

Re:Whee...

[vegiVamp]

Being rude for the sake of being rude is wrong, I agree. However, being pathologically friendly is also not the right answer: if a user asks "stupid" questions, you should point out in no uncertain terms where he is, what to expect and how to do his homework before bothering people with inane questions that a quick google could have solved just as well, but faster.

That does not mean you can't at the same time point him towards the answer, but it'll also help the willing ones get smarter while hopefully chasing the unwilling ones off.

Re:Whee...

[bmo]

"This car is so fucked up. I had to crawl under the car and patch together two wires just to get the windshield wipers to start.

Clearly a British car with electrics made by Lucas.

--
BMO

Re:Whee...

[Aceticon]

People are naturally lazy - they usually follow the path of least resistance without consideration for others.

I've seen this working in IT almost since I began - some people would just rather "ask somebody to fix this" than "try and figure out how to do it myself".

On the side of those being asked for help, being nice and polite and just giving them the answer doesn't help - it rewards and perpetuates that kind of behaviour: if one can easilly fix one's problems by asking somebody else to do it for them, then one will keep on "solving problems" by asking for help ... all the time.

After a while, if you keep being nice and solving everybody's else's problems, you notice that you're (literally) spending half of your time helping people who could've helped themselves.

At this point people become unpolite, even rude if they perceive the other side as asking questions because they're lazy. The best ones will try to teach the requester how to find the answers for themselves but that's it.

While for those asking the questions this might feel like unwarranted unpleasentness - after all, answering a single small question doesn't take all that much time - this is in fact a natural consequence of there being hundreds, even thousands, of lazy people out there who will happilly waste other people's time with questions they could find the answers for themselves if they tried a little harder.

Of course, most of us just stop answering the questions of strangers altogether.

Re:Whee...

[Geminii]

It's only because Linux users know enough to go seek help when they have the equivalent of a broken leg, so there's comparatively more traffic through the ER.

From what I've seen, many Windows users just keep dragging themselves down the street, entrails and spinal column sliding along in the dust, spouting bubonic plague from all orifices and using their jawbone as a crampon, and assuming the experience is normal.

Re:Whee...

[Kjella]

True. But if there's 100,000 users with a buggy wireless driver then spending an extra hour hand-holding one user with no clue and RTFM questions isn't doing anything to care for the other 99,999 waiting for a fix. There's a reason getting hold of developers is often difficult and require you to go through several layers of support to get to, and it is that these people are too important to deal with PEBCAK problems. They're not dealing with personal support, unless it's a bug that would affect a large number of people they aren't interested.

With open source and public mailing lists normal users get access to places end users would normally never see. There's no way you could mail a bug to Microsoft equivalent's of the LKML. I'm sure they have a "Windows Core Team" mailing list with all the chief people too, but it's employees only. And you don't post crap there unless you want an asschewing coming down the chain of command. The closest open source comes is separate mailing lists, sometimes the distinction is not that clear and sometimes people don't take a hint. Not everything is a support list or support channel...

Re:Whee...

[TrekkieGod]

Ever hear the expression "beggars can't be choosers"?

You know, if you see a homeless person on the street begging for money, and you decide to give them a very generous $10, but you do so by pulling out a huge wad of bills, taking out that $10, crumpling it up, and throwing it down on the floor where the man needs to jump on the floor to get it before the wind will take it away...you're a better man if you instead decide not to give him the money.

"Beggars can't be choosers" means that because the homeless person is in such dire straights, he will probably take the humiliation and grab the money anyway. It's not about giving you justification to be an asshole.

Re:Whee...

[Anonymous Coward]

The easiest / fastest way to get an answer and a timely response is to propose an answer incorrectly, then you will get experts tripping over themselves to sport their skill.

Re:Whee...

[MrNiceguy_KS]

Ah, Lucas Industries, aka "The Prince of Darkness". Partly because they're evil, but mainly because you never know if your lights will work.

"A gentleman does not motor after dark" - Joseph Lucas

Re:Whee...

[Ash-Fox]

Unix wasn't just used to run the telephone system, it was used by the military to launch Minuteman missiles, do operational control on navy ships and other jobs it wasn't specifically designed for. Doing certain changes would likely break some software somewhere, and occasionally new versions would result in phone calls from (armed) military people who where vivid in their descriptions of what they thought of the new changes, and were not willing to hear the word 'No' when demanding changes to the system.

So, that means Windows is the new UNIX.

Re:Whee...

[__aagmrb7289]

This post deserves every single mod point that can be thrown its way!!! Damn. I've already posted in this thread, or I'd give you all I could. Please - +3 insightful (which is where its at right now) is completely unfair. Someone mod this guy's post up, please!

Re:Whee...

[__aagmrb7289]

I agree that "pathologically friendly" is bad as well - that's why I say - just don't answer. Even an idiot will notice, sooner or later, that everyone ignores only them. And they might get a clue, or even ask "Why doesn't anyone ever answer MY question?" And then, politely, you can tell them, if you feel like it. And if they don't ever realize? Not your problem.

Re:Whee...

[vegiVamp]

Agreed, but a tad too far to the wrong side, for me. I prefer to point it out first, and ignore if they don't get it. Minor difference that may still save the willing quite a bit of time and frustration.

Re:Whee...

[adisakp]

Well, still, if they are "calloused to the suffering around them" it's still not a great endorsement of Linux. Either way it seems that most newbs have about as much fun getting Linux to work as they would spending eternity wailing in a lake of fire and asking for help in either case only gets you prodded with a pointed shaft.

Also from the article

[Weaselmancer]

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.

Re:Also from the article

[Anonymous Coward]

They are not the same. The kernel patch groups processes by owning TTY. The bash shell change groups them by session. Source: http://lwn.net/Articles/414817/

Re:Also from the article

[SharpFang]

The difference is the kernel patch is 200 lines of C code, which compiles to several kilobytes of machine code. The shell code needs to spawn a bash process upon startup of every other process, that's several megabytes of RAM and interpreting contents of text scripts that perform the operations.

The final effect may be the same but the overhead of performing the operation is much smaller with the kernel patch.

Re:Also from the article

[FooBarWidget]

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

[Anonymous Coward]

How does this effect servers?

I don't believe that it causes any servers to come into existence.

Re:Also from the article

[Anonymous Coward]

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".

Re:Also from the article

[by (1706743)]

It seems like a kernel command line option would be a great solution -- it would "just work" for the normal user, and the user with specific needs / servers / whatever could just append the appropriate few characters to the bootloader config.

Re:Also from the article

[brion]

Users won't need to recompile or reconfigure anything -- they'll get the updated system installed for them by the distro packagers in upcoming versions. You only need to do anything if you want to enable this *right now by yourself*, and there are indeed a few different ways to do it.

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. That's not due to it being in-kernel vs out-of-kernel though -- that's just because they are slightly different. 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. Do it once and leave it built-in to the kernel.

Re:Also from the article

[FooBarWidget]

Because that would put burden on the kernel team to maintain the code. Better to push things like this downstream so that the kernel team can focus on other things.

Re:Also from the article

[Goetterdaemmerung]

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.

How will it be more rapidly deployed by waiting for a distribution to make the change (or not)?

Since all software users use go through distros anyway it should be the distros' job to ensure user friendliness.

What if the distro doesn't bother with changing their init scripts? How does it make sense to put default process scheduling into their hands? I'll do you one better. Users->Distros->Kernel

Re:Also from the article

[adisakp]

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.

Umm no. It will be in the default kernal eventually and that works out-of-the-box. The idea that user friendliness is "pasting some lines to bashrc and running some commands" and that "user friendliness" should be left up to distros rather than the main line for Linux is pretty much one of the reasons Linux has never really mattered on the desktop and why 95% of computer users prefer Windows or Macs.

Re:Also from the article

[marcello_dl]

How does this effect servers?

I don't believe that it causes any servers to come into existence.

whereas "invoke-rc.d apache2 start"...

Re:Also from the article

[Anonymous Coward]

The newest version also groups by session

Re:Also from the article

[Geoffreyerffoeg]

No, incorrect. This is a modification to your .bashrc, which is (already) run every time you start a bash process, within that process (i.e., not a new process). Nothing needs to be spawned on every single process.

Admittedly the bash script does spawn some processes, but a) that's the way .bashrc works, and you have dozens of those in there, and b) it's only one process, a mkdir. The echo and the conditional run within bash itself.

The way that the configuration works, whether done in the kernel or in your .bashrc, is to associate all processes spawned from a single bash shell with a single new scheduling group. This gets you better performance when you're running processes from terminals, by associating logically-similar groups of processes in the kernel instead of letting it see all the processes as a giant pile.

The intended use case, which is pretty clear from the LKML discussion, is to make performance between something intensive (like a compilation) in a terminal and something non-terminal-associated (like watching a movie) better-balanced.

Re:Also from the article

[segedunum]

The effect is exactly the same. This is just Lennart trying to hijack another useful development thread and trying to tell us how systemd will solve everything.

Re:Also from the article

[horza]

As opposed to being in the default bashrc and work out-of-the-box?

Somehow I don't think the difference between pasting into a bashrc file or recompiling the kernel has been the deciding factor between Linux and Windows/Mac.

Phillip.

Re:Also from the article

[arth1]

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:Also from the article

[anomaly256]

Will this now require a desktop and server kernel? Where right now you can use the same kernel, and modify /etc/bashrc on desktop systems?

If you're that worried about performance, you'd be using server and desktop specific kernels anyway, like a lot of distributions do

Re:Also from the article

[Bloem]

I've read your comment several times and each time I hear the voice of comic book guy from the simpsons in my head. I'm not trying to be rude so I'm hoping you're not offended by this. I think it has to do with the "no, incorrect" part that your comment starts with.

Re:Also from the article

[jesset77]

Agreed. The last thing the Kernel team needs to worry about is improving the Kernel. D:

Re:Also from the article

[Anonymous Coward]

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

[SharpFang]

Okay, I've been wrong on spawning shell on every process.
Still, could you inform me when is /usr/local/sbin/cgroup_clean called?

Re:Also from the article

[wiredlogic]

I don't believe that it causes any servers to come into existence.

But we can presume that if it did they would be moody.

Re:Also from the article

[msclrhd]

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:Also from the article

[ArsenneLupin]

Seems your example shows that -t 0 doesn't work. In the case of make -j 64, each individual compilation's stdin is still a tty, so each would get its own group, defeating the purpose of lumping them together and "punishing" them for their aggregate rather than individual load.

PS1, on the other hand, is only set for the process at the root of the tree, so that one works.

Re:Also from the article

[ArsenneLupin]

Still, could you inform me when is /usr/local/sbin/cgroup_clean called?

When the shell that created the cgroup exits (i.e. when you close you terminal, konsole, or logout)

Re:Also from the article

[ToasterMonkey]

Umm no. It will be in the default kernal eventually and that works out-of-the-box. The idea that user friendliness is "pasting some lines to bashrc and running some commands" and that "user friendliness" should be left up to distros rather than the main line for Linux is pretty much one of the reasons Linux has never really mattered on the desktop and why 95% of computer users prefer Windows or Macs.

This whole thing sounds horrible, either way. Scheduling user owned sessions equally vs. giving the foreground application scheduling priority like OS X & Windows. I know kernel & userland integration is not a hot spot for Linux, but come on... we all know this is wrong.

Re:Also from the article

[julesh]

Somehow I don't think the difference between pasting into a bashrc file or recompiling the kernel has been the deciding factor between Linux and Windows/Mac.

Actually, in some ways I think it is. I can't comment about Mac, but in Linux the system startup process is needlessly convoluted, running thousands of processes due to the fact that it's implemented with a rather large number of shell scripts. Yes, this provides flexibility, but in many ways the Windows "services" system (a single process runs through a list of processes that need to be started and/or stopped and does this) is cleaner and easier to work with. It is certainly more efficient for the most common use cases.

Re:Also from the article

[FooBarWidget]

That doesn't count as improving the kernel, that counts as tweaking behavior that the kernel already supports. This tweaking can be done by external teams.

Re:Also from the article

[Anonymous Coward]

One never sets PS1 for non-interactive shells, and it's the primary way the shell tells the user's startup scripts whether they're interactive. There's a good chance the PS1 method spares a system call, too :-) It's also what the documentation says to do.

Your [ -t 0 ] approach also fails in cases where an interactive shell is being run on a non-tty. Although almost any shell since about 1990 tends to complain in such cases, at least the PS1 method will still run the right .profile code, and the -t method will not.

Re:Also from the article

[gl4ss]

apparently linus has the opinion that it should be in kernel and it will be.

which is smart, it's no good to require user scripts to achieve it.

this will mean it's going to be in any future releases. if your linux vendor updates it's kernels it's going to be there(not all do.).

Re:Also from the article

[marcosdumay]

Windows way is not clear, but is more efficient. Anyway, you use a Debian based Linux, doesn't you? Most distros that don't package the entire world did already come with a replacement that works form them and is at least as efficient as the Windows way.

It is just that you can't have the biggest software repository of any distro available to you and use a not flexible startup routine. Or, to correct myself, you can, but you'll have to choose the routine that works for you, like you can do on Debian. It is just that you can't have the repository and a not flexible startup routine installed by default.

Re:Also from the article

[jedidiah]

I'm not sure you are in any position to lecture anyone on how init differs from anything else or why it matters.

Re:Also from the article

[bluefoxlucid]

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. Do it once and leave it built-in to the kernel.

Exactly, which is why we got rid of that udev thing and pushed for devfs. udev needed way too much configuration and extra scripts and a daemon running and other bullshit, while devfs just works.

Re:Also from the article

[bluefoxlucid]

(a single process runs through a list of processes that need to be started and/or stopped and does this)

Yes that's sysvinit. Upstart is a bit more advanced (event reactive and dependency aware).

Re:Also from the article

[ginbot462]

The intended use case, which is pretty clear from the LKML discussion, *snort* ...

Re:Also from the article

[mcgrew]

user friendliness" should be left up to distros rather than the main line for Linux is pretty much one of the reasons Linux has never really mattered on the desktop and why 95% of computer users prefer Windows or Macs.

95% of computer users never even heard of Linux. Of course you're going to "prefer" something you've used for years over something that you don't have a clue even exists.

Re:Also from the article

[arth1]

Seems like you don't know how .bashrc works.
A "make -j 64" doesn't call .bashrc 64 times; nor once.

It also seems like you don't know how job control works for make. Only the parent jobs will inherit a tty; children won't[*].

Unless you have makefiles that do things like outsourcing jobs with ssh, that shouldn't be an issue (and in those particular cases, you probably DO want separate groups too).

Quite frankly, chances are probably WAY higher that a user sets PS1 in .profile to change the prompt, like he's done since the days of SysV.

[*]: You could even use the fact that only parents have ttys in make to your advantage: If all your compiles went through a compile.sh script (or generic compile rule) that deliberately checked for -t 0 and set a cgroup, you would would get one new group for every N in -j N, for interactive compiles only. This could be very useful on a system where automated builds run in the background, and you want to prioritize manual builds.

Re:Also from the article

[ookaze]

Umm no. It will be in the default kernal eventually and that works out-of-the-box. The idea that user friendliness is "pasting some lines to bashrc and running some commands" and that "user friendliness" should be left up to distros rather than the main line for Linux is pretty much one of the reasons Linux has never really mattered on the desktop and why 95% of computer users prefer Windows or Macs.

This is pretty irrelevant here because the people affected by this patch and benefiting from it are all deeply involved in Linux already.
What you say is even more irrelevant because this patch won't affect in anyway those users that prefer Windows or Mac (users used to graphics and not to command line) if they ever happen to try Linux.
To add to the ridicule of what you're saying, the kind of workload causing this scheduling problem (the heavy stress on the CPU scheduler) are just unsustainable on both Windows and Mac.

The problem here is clear to me : this is a userspace problem that they include in the kernel. It's a userspace problem because you don't actually need one addition of this kind to make it effective, you need one for every workload you happen to fall upon. Which means it must be configurable, and if you put that in the kernel, you then have to put the myriad other workload corrections in the kernel, or you'll have inconsistencies, with some workload treated in the kernel, others in userspace.
This is a policy problem basically, and I just don't understand how the kernel developers can say it's sane to put this in the kernel.
Of course one patch of this kind is not bloat, but as soon as you start adding the corrections for other workloads, it'll add huge bloat to the kernel. This doesn't make sense to me.

Re:Also from the article

[animaal]

How does this effect servers?

I don't believe that it causes any servers to come into existence.

I know you're having a laugh, but that sums up my experience of help from the Linux community - technically correct, but obviously doesn't help the poor guy.

Re:Also from the article

[jon3k]

Any distro could release an updated kernel with the patch. But what you're describing isn't Linus's problem, it's a distro problem. He fixes the problems at the source and it's up to the distros to fix them downstream.

Re:Also from the article

[quickOnTheUptake]

Yes but, assuming I'm following this, very little real desktop stress is created in a neat little TTY.
For most desktop users really high load is caused by X programs that don't run in a tty. (run ps -A and see how may ?'s are in the second column)
The real solution to better desktop performance is
A)to make X a little less network transparent so it will reliably report PIDs to the window manager (at least for apps running locally, which for most people is all of them, and moreover even if there are some running on a foreign host, they won't be the ones to bring the local machine to its knees). ATM you have to rely on the _NET_WM_PID atom which is entirely voluntary, and some major--both in terms of users and memory footprint--programs don't set it (OOo).
And B) make it so that users can renice their own apps to lower values, as long as it follows some policy, e.g., a normal user can't set his processes' nice value below 0. There is no reason I can think of for a blind only-root-can-ever-lower-the-nice-value-on-any-process policy.
If we did these two things, then the window manger--which actually has the information about what window and process needs to be responsive (i.e., the one with focus) and which don't (i.e., ones that are unmapped/minimized/on-other-desktops)--could dynamically alter scheduling priority in an intelligent way instead of the kernel trying to guess what is interactive and needs low latency and what isn't.

Re:4 Lines Is Not All. Let's Not Forget...

[rubycodez]

nah, a few lines to the system-wide /etc/bash.bashrc should do just fine

Re:old-school meet olds kool

[WillAffleckUW]

Racing stripes do the same thing and are much prettier.

I find magnets work best of all.

Why isn't the good old 'nice' command suitable?

[zmedico]

Isn't the good old 'nice' command intended for scheduling priority adjustments like these? Can someone explain why the 'nice' command is not suitable?

Re:Why isn't the good old 'nice' command suitable?

[icebraining]

The problem is, 99% of process run by a heavy GUI desktop user have the same TTY as well. They only change if you start something from a terminal.

Would be nice if DEs could add processes to different cgroups. Then each application and its children would be in a different cgroup, like (Firefox+plugin-container), (mplayer), (terminal+make+gcc+ld), etc.

Re:Why isn't the good old 'nice' command suitable?

[El_Oscuro]

It should be - even on Windows. I was using scp from CYGWIN to transfer a large file to a Linux server and the encryption was eating up all my CPU. I couldn't do anything else at all. Try to open emails, access web pages, nothing would work while the copy was running. I used nice with the command and checked task manager. Sure enough, the CPU was still at 100% but as soon as I did anything else, it responded perfectly. The CPU was always at 100% but when running nice I couldn't tell it from the other applications.

Adding nice to your Desktop should be easy too. Just edit the shortcut and add nice to the command, i.e.: nice firefox (I am running this browser with nice and can't tell any difference)

Re:Why isn't the good old 'nice' command suitable?

[cynyr]

yes, but when 90% of everything is run from the desktop....

Re:Why isn't the good old 'nice' command suitable?

[Bengie]

nice isn't the perfect way to make things work. You may want an app running high priority, but you still need a little cpu to do basic GUI interactions.

I'm not trying to say Windows is better, but they did a few really nice things with the Win7 kernel.

Win7 counts clock cycles that each thread consumes. If a thread wakes up and goes back to sleep, it consume very few cycles. On the other hand, another thread may consume it's entire time slice. In order to keep other threads from getting starved, it will artificially increase priority for threads that consume little cpu, but wants to wake up. Win7 also has a new audio api to allow low latency audio. The idea is that audio consume very little cpu, but it needs to get processed fast and on time every few milliseconds.

Couple this stuff together and you have a responsive gui under heavy load. An easy test that I did is I loaded up prime95, set it to high priority and let her rip. Loaded up a 1080p movie and playback was flawless.

IO priority is nice to. load up defrag, set to idle priority, start virus scan(good virus scanners use new IO api options), play games. By default, idle priority threads get low priority for IO also. This kind of stuff can also be programmed via API(virus scanners rawr) so a normal priority thread can have an idle/low priority IO.

By default Win7 has 20% cpu on standby, so "starved" threads can fight over that 20%. This can be disabled and is disabled by default on Server 2K8R2 and not an option on just 2K8. This keeps things feeling peppy.

This is probably why my 1080p videos play just fine even with prime95 at high. A video/audio track can be buffered, so even though Prime95 is trying to starve the system, all my other threads still get up to 20% cpu. On and i7, 20% cpu is a lot of processing power. I would assume a realtime processing like a video game would get stuttering since it can't buffer much and getting starved for a few milliseconds is gonna to cause break up.

I would love if Linux had more options for schedulers. In another ./ posting, someone mentioned that there was talk about a pluggable/module scheduler, but that got turned down. I could see an idea like this being useful so the user could have specialized scheduling, especially for desktops. May be even just modulized logic on how the scheduler should handle starved threads.

Again, I'm not trying to say Win7 > Linux or anything, I'm just recognizing a good idea that works.

Ubuntu instructions incorrect

[mister_playboy]

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
mkdir -m 0700 /dev/cgroup/cpu/user/$$
echo $$ > /dev/cgroup/cpu/user/$$/tasks
echo "1" > /dev/cgroup/cpu/user/$$/notify_on_release
fi

Re:Ubuntu instructions incorrect

[Anonymous Coward]

It's fixed now

Re:Ubuntu instructions incorrect

[nanospook]

Could you be a little ruder about this? Does this help? How do i get this to work on my Windows? :0 Seriiously thanks for the tip!

Re:Ubuntu instructions incorrect

[martin-boundary]

Yeah, yeah. Hey retard! I don't have gedit, so can I maybe type that in vi on a 1200 baud link from my PDP11's terminal instead? Think about your users, dammit! We're not all computer geek geniuses! These instructions are sooo useless!!!1!! Fuckit, I don't have time for this, I'm going to reprogram the EEPROM on my 1984 vintage solar powered wristwatch, your project sucks you people are so rude!

Re:Ubuntu instructions incorrect

[equex]

I use Ubuntu 8.04 LTS with kernel 2.6.24-28-generic, and I get these errors on starting a terminal:

bash: /dev/cgroup/cpu/user/9202/tasks: No such file or directory
bash: /dev/cgroup/cpu/user/9202/notify_on_release: No such file or directory

(the number is different every time, it's just a PID, right ?)
I'm sure I followed every step correctly and I didn't try this before the corrections came up. Anyone have any ideas ?

My /usr/local/sbin/cgroup_clean reads:

#!/bin/sh
rmdir /dev/cgroup/cpu/$*

My /etc/rc.local reads:

mkdir -p /dev/cgroup/cpu
mount -t cgroup cgroup /dev/cgroup/cpu -o cpu
mkdir -m 0777 /dev/cgroup/cpu/user
echo "/usr/local/sbin/cgroup_clean" > /dev/cgroup/cpu/release_agent

And finally I have this at the bottom of .bashrc:

if [ "$PS1" ] ; then
mkdir -m 0700 /dev/cgroup/cpu/user/$$ > /dev/null 2>&1
echo $$ > /dev/cgroup/cpu/user/$$/tasks
echo "1" > /dev/cgroup/cpu/user/$$/notify_on_release
fi
All permissions should be right too.

Re:old-school meet olds kool

[Anonymous Coward]

Use the TURBO button!

What does this do?

[adenied]

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?

Re:What does this do?

[icebraining]

Imagine you have an app that launches just one process, like a music player, and an app that launches 3 (for example, Firefox, which launches a new one for each plugin).
Since each process has the same priority, the second app - firefox - will effectively have 3x more CPU time than the media player, and possibly stutter the music.

The kernel has something called cgroups, which enables more than one process to be grouped, and each group will have the same CPU time. So the group (Firefox+plugins) would have the same CPU time than the media player.

This kernel patch and terminal code enables each terminal you launch to have a different group, so if you launch Firefox from one terminal and the music player from another, they'll have different groups.

Re:What does this do?

[Tacvek]

Sure.
Hopefully you know what a TTY is, but in case you don't it it a virtual or real terminal. When you open up an xterm you create one. If you don't have x-windows installed, you reach one, etc.

Well Linus had an idea about using a grouping functionality that was already in the Kernel to allow all the processes (technically actually all the kernel threads) running from one TTY to be grouped together for scheduling.

The result of that is that if you are running 99 processes in one xterm that could consume all of your CPU, and you open another xterm, one one just one process that wants 100% CPU, each xterm's processes gets 50% of the CPU, rather than one getting 99% and the other getting only 1%.

But lets say you only had that first xterm. Since each of those processes are not getting nearly the processor amount they desire, normally the scheduler sees them as nearly starved, and the next process that only wants 5% of CPU does not get much preferential treatment for giving up most of it's time. However, with the grouping, the scheduler can see that those 99 processes are related, and they are not really starved, since as a group they are getting 100%. So now when this other app that wants only 5% comes along, the scheduler might give it pretty much all of that 5% rather than the mere 1% it would have been getting before, and so that app (probably a web browser or something) remains nice and responsive.

That is not 100% accurate, since I've simplified some things a little, especially with regard to the working of the scheduler, but it should give you the idea.
Eventually, more heuristics might be added, so that a GUI application that launches a bunch of threads and hogs the CPU might have all it's threads grouped, so they don't hurt responsiveness of interactive apps either.

Re:What does this do?

[tinkerghost]

OK this is a vast oversimplification & if someone else has a better description feel free:

Either way you do this, Kernel level or Userspace, you're grouping tasks in the scheduler. The theory is, you take all your GUI programs & schedule them as independent tasks, and then lump all your non GUI software as a single task.

Since all your GUI software is marked as independent tasks, they each get a timeslice on every scheduler rotation. All of the non GUI tasks share a single timeslice. This prevents a task that's hogging the CPU (compiling in the test example) from locking out the other software & creating the lag that's common under a heavy workload.

There's a slight difference in the approaches to grouping tasks, but they are effectively the same technique.

Re:What does this do?

[bobbuck]

I still think that the problem is that everything runs with the same priority. If I have three processes: watch_tv, answer_phone, and extinguish_fire, the kernel or its developers are just making wild guesses about which one to run if the priorities are not set properly. Should I idle extinguish_fire to improve watch_tv's interactivity? The distro's should set reasonable priorities on things instead of expecting psychic powers from the kernel.

Re:What does this do?

[h4rr4r]

So what is reasonable?
Should we favor firefox over mplayer? Or the other way around?
What if you are using mplayer to only watch security cams and firefox to watch something on hulu/youtube/vimeo?

Re:What does this do?

[tinkerghost]

In theory you could alter the 'launch' process for running software & check a database for 'nice' priorities so that they automatically launch with a preset 'nice' rating.

Currently, the kernel is very egalitarian - everything runs at 'nice 0' unless the user wants something different. If YOU think that extinguish_fire should have more of a priority than watch_tv, then YOU should handle the issue.

However, that isn't the issue addressed by either the patch or the userspace scripts. While adjusting niceness may help in a gross sense, it's not going to handle proper timeslicing of software that's spawning a huge number of threads and lagging other applications.

As an example, we need to run extinguish_fire and evacuate_building at the same time. extinguish_fire spawns a thread for each bucket in the brigade, while evacuate_building only spawns a thread for each escape route. Now, if there are 96 buckets & 4 escape routes, extinguish fire will consume 96% of the CPU & choke out the evacuate_building threads.

You could try to guess the appropriate level of 'nice' for each program when you launch it, but it's not going to be pretty. To get even timing, you would be pushing evacuate_building to nice -19 - an act that would make it next to impossible to establish any control over the bucket brigades.

By grouping all of the threads from a program, extinguish_fire and evacuate_building get equal footing regardless of the number of threads they spawn. Both of them remain responsive to commands without taking the huge hits you get from drastic nice levels. If both processes aren't running smoothly, you can renice the group rather than take the nice hit 'threadcount' times.

Re:What does this do?

[Chuck Chunder]

Either way you do this, Kernel level or Userspace, you're grouping tasks in the scheduler. The theory is, you take all your GUI programs & schedule them as independent tasks, and then lump all your non GUI software as a single task.

I think you have it backwards, neither the kernel or userspace code mentioned here is effecting GUI apps, they remain lumped into one group. It's only giving things that have their own TTY (ie a terminal window) their own cgroups. As such it's only provides advantage in certain cases (when a process is launched in a terminal).

I think the 'userspace' method makes more sense.
Not because the particular userspace implementation here is great (it more or less just does the same as the kernel implementation) but because a userspace implementation may be better placed to understand what the user is doing and assign groups accordingly using information other than just the TTY. Perhaps it could promote a process focussed in X to it's own group, or an app running in full screen mode. Perhaps it could lump minimised apps in with other non-critical things. They are all just ideas pulled out of the air but I'm not sure the kernel itself would have the necessary information to make such decisions.

It's GUI users that have the most to gain from improved interactivity but it should be fairly obvious that grouping based on TTY isn't going to bring much advantage to them. Both versions of the code here suggest that improvement is there in the kernel waiting to be leveraged, it's just a matter of someone making the improvement generally applicable.

Re:What does this do?

[PReDiToR]

Isn't that what nice is for?

Re:What does this do?

[godrik]

"Eventually, more heuristics might be added, so that a GUI application that launches a bunch of threads and hogs the CPU might have all it's threads grouped, so they don't hurt responsiveness of interactive apps either."

First thing I do when I got this patch in: write a wrapper to firefox that starts it in its own group. So that it stops killing my desktop because of crappy javascript or flash!

Re:What does this do?

[martin-boundary]

Why should the groups be attached to the launching terminal? Wouldn't it make more sense to use the natural shape of the process tree (pstree) itself? The immediate children of init ought to all get the same priority, no?

Re:What does this do?

[Tacvek]

The group feature is already there for those that want it, but it is not enabled by default in most distro kernels.

They create a hierarcy.
The scheduler looks at schedulable items, not caring if they are threads or groups, and uses its normal algorithms (including nice levels) to decide which to run next. If it chooses a group, it repeats this process for the group, and of course, all time used by processes or subgroups count towards the group's running time. It repeats until it gets an actual thread, and runs that.

I'm not sure how one sets the nice level for a group though. I only learned about this feature yesterday when reading the LKML thread.

Re:What does this do?

[bobbuck]

If you mean YOU as in the distribution maintainer, I agree 100%. There are somethings that should usually be at a higher priority (audio/video, X) and some that should be at a lower priority (make, gcc) As for the threads, I see your point. I just get aggravated when I have a 2GHz machine with 2GB of memory and I can't log in without the Ubuntu "Happy Login(TM)" sound stuttering.

Re:What does this do?

[bobbuck]

Yes, but I think some sensible defaults for niceness would improve things for the regular joe.

Re:What does this do?

[a_n_d_e_r_s]

Cause it is the natural shape of the process tree.

Init is the grandparent and terminal is parent of all programs launched from the terminal - that way you can control the processes using the terminal.

The patches just move a terminals children into different groups.

Re:What does this do?

[GooberToo]

Schedulers are extremely complex. Changing priorities can have very surprising and often, completely undesirable side effects, including things like

Simply changing priorities of processes without understanding their impact is not something the average Joe should be doing. Likewise, chances are assumptions which would be made by, "reasonable priorities", are almost certain to be wrong for a large number of users and their workloads. And in fact, would be far, far worse than the current situation with the existing, implementations.

Re:What does this do?

[tinkerghost]

The only time I would say a distribution should be involved in setting priorities would be if the actual process of launching software checked a listing. Even then it's highly suspect, in a lot of ways, nice is a sledgehammer for a problem that needs a scalpel.

From the looks of it, the hooks for group control are already in the kernel, if a launcher were written to take advantage of it, distros could easily set the launch commands for the response sensitive software to their own groups & leave less sensitive software to fall in the main window manager group.

Re:What does this do?

[GooberToo]

I clicked on the wrong article and noticed I boned the link in my reply. The link is for priority inversion. And that's just one sort of issue which can complicate playing around with priorities.

Re:But But But But Buzt Buut

[Gordonjcp]

Why should a user have to bother doing this in the first place just to have a responsive desktop system?

They don't. It's helpful if you are doing certain things that show up behaviour that the patch or the commands described above can counteract. If you don't do that (and it appears to be most helpful at speeding up your desktop if you are *at the same time* compiling huge programs, and similar work, which most desktop users don't do) it won't make much difference.

GNOME still has a turbo button

[tepples]

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.

Re:GNOME still has a turbo button

[h4rr4r]

I have my phone doing this, if charged and plugged in it clocks to 1.2Ghz.

Re:GNOME still has a turbo button

[Suki I]

I have my phone doing this, if charged and plugged in it clocks to 1.2Ghz.

Does it burn your face when you overclock it?

Re:GNOME still has a turbo button

[h4rr4r]

No, only gets to about 100F on the CPU.

DOes it really make any difference

[HelloKitty2]

With my new 100/100mbit broadband, and the fastest SSD, and this hack, I'm not sure I'm noticing anything ;O

Re:DOes it really make any difference

[Provocateur]

But animals within range of your home, did, at the slightest instant, raise their heads and went, WTF was that??

Re:DOes it really make any difference

[kb]

So when you surf the interwebs, the mp3 player STILL stutters? :D

Re:DOes it really make any difference

[cynyr]

It's been a very very long time since I've managed to make audio stutter on linux, and that was on a P100 that needed 95% cpu just to decode an mp3. ohh maybe i managed to make it stutter running dbench on the same drive my music is on. but that's about it.

Re:4 Lines Is Not All. Let's Not Forget...

[blair1q]

I still use csh(1), you insensitive clod!

Re:4 Lines Is Not All. Let's Not Forget...

[RyuuzakiTetsuya]

/etc/bash.bashrc

Global bashrc file.

Re:old-school meet olds kool

[h4rr4r]

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.

2 Commands and 4 lines!?

[rsilvergun]

Luxury! Utter Luxury! In my day we did it with 4 commands and 8 lines... In the Snow!

Re:2 Commands and 4 lines!?

[cynyr]

and up hill both ways? with tires for shoes, over cacti?

Re:2 Commands and 4 lines!?

[garethw]

Mix memes much?

Re:But But But But Buzt Buut

[EvanED]

It may be an old kernel problem or a configuration problem, but it certainly isn't an old machine problem. I'm posting from a dual quad core two-way hyperthreaded Xeon (yes, that's 16 HW contexts) and I've faced stuttering on a number of occasions. Sometimes it's app specific (Firefox, I'm looking at you) and sometimes it's been system-wide. Usually the latter seems to happy in periods of heavy I/O. OS is RHEL 5.

Re:But But But But Buzt Buut

[h4rr4r]

1. stop using RHEL 5
2. make sure the hyperthreading is actually helping. Under many workloads it actually hurts performance.

Following in Windows' footsteps, but backwards

[broknstrngz]

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.

Re:Following in Windows' footsteps, but backwards

[imroy]

IIRC, Windows favors processes with a hWnd over those without one.

IIRC, Linux has favoured interactive processes (those with an attached TTY?) for a while as well.

I guess this is roughly the same thing, but the other way around.

No it's not. It's about grouping processes ("tasks") to even out the amount of processor time portioned out. So, from the example, you can compile a kernel with "make -j 64" (i.e running 64 parallel compiler processes) and your video/music player will still play fine because each group (your player and the compiler group) is getting about 1/2 of the system CPU time instead of each process (your player and 64 cc1's) getting 1/65.

Re:Following in Windows' footsteps, but backwards

[broknstrngz]

I meant roughly speaking. I am aware of the details :)

Haven't touched Linux in a long while, I'm a BSD guy, but even we have (or used to have) KSEgs ;)

Re:4 Lines Is Not All. Let's Not Forget...

[fahrbot-bot]

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.

Re:But But But But Buzt Buut

[E IS mC(Square)]

>> Just curious what others think.

'Curious' my ass. You have a history of trolling anything and everything against Apple or pro google or pro open source. If you want to troll, there are more subtle ways.

Lennart is right - the kernel patch is the hack.

[neiras]

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!

Hacking the bashrc

[janwedekind]

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.

Re:Hacking the bashrc

[tinkerghost]

If you launch things from a desktop icon, it'll get dumped into the same group as your window manager.

How to get it dumped into a different group is the variation on the 2 techniques. The patch requires you launch the program from a different TTY, the script requires it be launched from a different session.

Perhaps something like a nice command could be created that will dump things into the specified group:
kgroup -n firefox firefox

Software that needs to stay responsive or has the potential to bog down the system can be set to instance it's own group, while other software can be lumped into the generic session group.

Mandrake User's Board

[nanospook]

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..

Re:Where do I put this again?

[h4rr4r]

Put the phone in airplane mode.
Then be amazed.

Re:4 Lines Is Not All. Let's Not Forget...

[h4rr4r]

So then why is your UID so high?

I will get off your lawn now.

Poettering ad hominem

[jensend]

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.

Re:Poettering ad hominem

[Abcd1234]

Favorite Poettering quote from this discussion

Oooh ooh, let me try! I love this game. Quote, here we go, my favorite quote from jensend about Poettering:

"Since he's so brilliant and all, his design (done without consulting much with lesser mortals ) must be right"

See, you love him, you just don't realize it!

Re:Poettering ad hominem

[jensend]

Well, if taking that quote out of context gives you a chuckle or at least an ironic smirk, all the better. That's what I got out of taking the Poettering quote out of context and felt like sharing- of course it didn't prove anything.

I certainly don't hate the guy, and he's got a lot of talent and interesting ideas. It just seems that things would work out a lot better for everyone if he were a little more ready to consider others' ideas esp. if he actively solicited design input from those most likely to be impacted by his "brilliant redesigns". His saying over and over that Linus is an idiot for wanting to make tty-based cgroups an in-kernel default doesn't exactly inspire confidence in the notion that this ought to be in user space.

Re:Would it absolutely kill you to explain this?

[cynyr]

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.

Re:Lennart is right - the kernel patch is the hack

[Wonko the Sane]

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.

Re:4 Lines Is Not All. Let's Not Forget...

[rubycodez]

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.

Why not both?

[Culture20]

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?

Hurray for Open Source Software!

[Ustice]

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.

Re:But But But But Buzt Buut

[jvonk]

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?

Re:4 Lines Is Not All. Let's Not Forget...

[fahrbot-bot]

So then why is your UID so high?

I was busy - working.

Re:But But But But Buzt Buut

[flnca]

I guess this is just for the ones who want a solution right now. The others still can wait until the next kernel update, which will probably include the 200-line patch.

Re:old-school meet olds kool

[Suki I]

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!

I Just Paint My Case Red

[Bacon Bits]

Every grot knows da red onez go fasta!

Putting the code in the wrong place

[ras]

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.

Re:Putting the code in the wrong place

[Kjella]

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 better question is, do you ever want your video to start flickering or your music to drop out? No? Then there's not really much mind reading that needs doing, schedule them whatever they need and let the transcode get the leftovers. If the CPU priority isn't enough, then really it's not achieving its purpose.

Re:Putting the code in the wrong place

[Luyseyal]

The problem is that X applications are still grouped together. The nice thing with a user-side app is that if you're using a bunch of GUI apps hogging the CPU, a smart KDE/GNOME session daemon could tell the kernel to group them together. E.g., the app registers itself to the daemon as typically non-interactive or interactive. That way, the non-interactive stuff is grouped together and scheduled like they're under the same PTY.

$0.02USD,
-l

P.s., I still think the kernel patch should go in just for sane defaulting. But the GNOME/KDE thing would be a nice improvement.

Re:Putting the code in the wrong place

[marcosdumay]

At 2.4 kernels there were a fake "real time" priority that didn't let your music flicker (by the time, on lots of cases 100% of CPU just wasnt eough for video). I don't really know why it was taken out of 2.6.

Re:Putting the code in the wrong place

[Lennie]

permissions I guess.

The real time prioritoy is still their, you just need superuser rights to set it.

I guess we should just have more permissions as desktop users, or some group we can add the users to.

Re:Putting the code in the wrong place

[PybusJ]

OK, reasonable points. But why do we put up with basing the scheduler on various heuristics anyway. The kernel might need to mind read, but users of the system know what they want (and more importantly so do those configuring the distro).

There seem to be two sensible lines of attack which avoid mind reading:

1) Applications are given reliable ways to tell the kernel what performance they need. Every packager knows that mplayer is latency critical and needs to avoid CPU starvation, and that make wants thoughput, but is a batch load. So why is the scheduler guessing?

2) Feedback. Does the scheduler know when it's getting things right? Does mplayer have a way of indicating that it's dropping frames? The desktop environment knows which window the user has in focus, does the kernel? If you can measure what effect you're having (and you've been told what's wanted) then scheduling without mind reading gets a whole lot easier.

Getting an algorithm to schedule CPU time while best meeting the demands of many processes isn't easy, but I don't see a need for guesswork in the requirements.

Re:But But But But Buzt Buut

[EvanED]

1. stop using RHEL 5

Not an option; it's not a personal box.

2. make sure the hyperthreading is actually helping. Under many workloads it actually hurts performance.

I might be able to arrange that (though again it's not a personal box), but the stuttering shows up even when the overall CPU load is light. I can just have stuff like Thunderbird, Firefox, and a music player running and if I link one of our projects (one core, heavy on the I/O) sometimes the audio will stutter and the overall desktop will become extremely laggy (e.g. seconds to change virtual desktops).

Theoretically the kernel could be doing something stupid like scheduling the linker on core 1, thread 1 and Clementine on core 1, thread 2, but I'd expect even an older version to be smart enough to do that. Even so, I wouldn't expect it to be that bad even if the scheduling is fine.

It almost reminds me of a problem I had the first time I installed Gentoo. I didn't compile the right driver for my motherboard, which resulted in it not being able to do DMA to the hard drive. So theoretically it could be something stupid like that. (Actually, now that I think about it, it might be worthwhile to investigate. Anyone know how to tell whether it's doing DMA? Preferably as non-root because then I don't have to get the IT folks involved.)

Re:But But But But Buzt Buut

[GooberToo]

Under most common workloads, hyperthreading actually costs 20%-30%. The majority of users should have hyperthreading disabled.

How did BeOS do it?

[psych0munky]

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

Re:How did BeOS do it?

[ledow]

It's just properly preparing a computer for interactive desktop use, something which few distros seem to bother to do. As both the patch and the shell script demonstrate, the functionality has been there for ages and even before it was, you could fake something similar. Hell, even Windows just used to give a priority boost to the window that was in the foreground but I remember at the time that being ruled out because it might interfere with server operations on Linux and so the user was left to do that themselves if they wanted.

All either approach does is put each process in its own group so that the resources allocated to one process don't take up a disproportionate amount of the overall resources. It's nothing that we haven't been doing since the early days of multitasking operating systems, it's just that someone worked out that on a modern machine, grouping processes actually works better for an interactive desktop experience than not.

Most Linux computers *aren't* on desktop workloads, so it's useless there because you will get processes starved of attention where you want them to run at full-speed. But the ones that *are* on the desktop should *always* have had scheduler and priority tricks like this because it's been obvious for decades that it makes sense. Nobody bothered because, to be honest, on all the Linux desktops I've ever deployed, running a computer that's that heavily loaded hasn't been advantageous whether or not you could smoothly play back a movie. Most desktops for inexperienced people actually have a single app with the main focus all the time. Even advanced users can struggle with more than a handful of programs running simultaneously. And anyone who's running an amount of processes such that the computer slows to unusable levels in most of them obviously doesn't care about getting the work done on time if they just zap the processes into groups and balance priorities. Yes, your desktop might keep playing HD videos but your kernel compiles are going to take FOREVER while they do that - no different to any other OS. And, let's be honest, how many desktop users actually load their systems heavily enough that they can't watch an HD movie on the kind of hardware that the patch was benchmarked on?

It's an interesting observation of a modern implementation of a very old solution to an almost-non-existent problem. That's why someone is able to look at the patch and do it better in a handful of shell script - it's not rocket science, it's just that nobody bothers to do it for desktop systems. And if you do, then mainly it means that your desktop system is trying to do too much and/or isn't really that vital for you (i.e. if you can't be bothered to move off your kernel compiles to a remote machine, chances are you don't care if they finish in 2 minutes or an hour and thus is your probably *do* want to prioritise your HD movie playing or whatever).

Personally, I never have to play with nice levels or process groups because on my servers I want things to run at full speed and the CPU's are rarely that loaded that having another machine or having strict fairness imposed would help matters, and on my desktops everything works "good enough" and I don't really *want* to try a 64-process kernel compile while watching a HD movie, even if it stands 0.1% chance of making the movie a little jerky. I'll move it off to another machine, do it overnight, wait until the movie is finished etc. because it will then complete in a matter of minutes rather than having to fight for CPU with my HD movie. If I'm compiling a kernel and can't afford a handful of minutes to wait for it to compile, why would I be able to wait, say, an hour and watch an HD movie in the meantime?

I've just used the example loads posted on the patch benchmarks but the same thing holds - if you're at 100% CPU then you have to make trade-offs and this patch / script makes better trade-offs for interactivity at the expense of overall speed. But if you're at 100% CPU then something's probably wrong in the f

Re:How did BeOS do it?

[marcosdumay]

"All either approach does is put each process in its own group so that the resources allocated to one process don't take up a disproportionate amount of the overall resources."

They way it was ever done (including the BeOS way) is way simpler tough, every time a process doesn't use all it's CPU, you give it a boost by placing it near the begining of the execution line. That is enough to make interactive processes (the ones that don't use all of its CPU) responsive. That, by the way would kill the performance of a server, and that is why Linux doesn't work that way. Of course, that is also why the pluggable scheduling was proposed, so we could have responsive desktops and fast servers, but it was rejected for some reason.

But the above doesn't work for media, so (by the time media started to spread to computers, that means, by the 90's) people solved the media problem in another way. You just have to mark the media processes somehow, and give them all the CPU they want. Linux did that by the 90's, but dropped the feature for some reason.

Re:How did BeOS do it?

[amn108]

I would speculate that BeOS went about the UI latency another way. I think what they did was to actively handle keyboard and mouse interrupts in a way where on each such interrupt BeOS would wake up the process that handled and routed the messages according to which window these should go, with processes that owned this window getting on top of the CPU-task-switch list. On top of that, they might intentionally slow-down (buffer) certain interrupts, such as mouse movement, if they trapped these at all, so that these would not have other I/O driven processes starve for CPU-time. But like I said, I think the clicks would be handled immediately.

This is in contrast to Linux, where the keyboard and mouse interrupts do not explicitly cause any process to wake up, but where these end up as events in an event queue of a process and then the CPU scheduler by its usual way of going about things wakes up each process (with CFS it will basically do a round-robin of sorts). So when you click a mouse, Linux does not really care - your mouse event simply ends up in an event queue, and then a process that wants to listen to these events does something about it, with the DIFFERENCE that it will only do that when it gets CPU-time, in its due time. When said due time is longer than necessary, users complain, and so it is the job of CPU scheduler to switch to processes that handle UI events as soon as it possibly can, while at the same time give necessary time to I/O driven processes churning away in the background at all times. In short Linux prioritizes processes, while BeOS prioritizes user initiated events. When Linux CPU sheduler is as good at giving event driven processes his attention promptly as BeOS is at not starving IO driven processes, both will be of roughly equal performance. However, I would prefer BeOS' way of doing things.

Re:Lennart is right - the kernel patch is the hack

[neiras]

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.

Re:If you were looking for an example

[Blakey Rat]

Because you can hack together a close approximation of a feature that's in an unreleased upcoming kernel? A feature that every other OS has had for 3+ years now?

Yah, I'm bowled over.

Re:But But But But Buzt Buut

[Anonymous Coward]

hdparm, but it requires root.

Re:If you were looking for an example

[QuantumBeep]

Hey, look! It's one of those miserable people! What's it like being unable to like anything, ever?

Re:But But But But Buzt Buut

[arndawg]

But think of the penguins! Would you really want users to kill half of their precious?

Re:Lennart is right - the kernel patch is the hack

[amorsen]

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.

command line hack works on Kubuntu 10.10

[alizard]

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.

Re:4 Lines Is Not All. Let's Not Forget...

[ArsenneLupin]

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.

Re:4 Lines Is Not All. Let's Not Forget...

[ArsenneLupin]

I was busy - working.

Get a place where you don't have your back towards the door...

Windows mentality breeds windows mentality

[ArsenneLupin]

One of my pet peeves is users who don't read (or don't try to understand) error messages.

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"

Re:Windows mentality breeds windows mentality

[marcosdumay]

"their programs won't display meaningful messages because "nobody ever reads them anyways", even if it is a program intended for Linux."

I doubt that will be the case. The value of error messages become evident as soon as you need to remotely debug your project, what happens as soon as it becomes sucessfull. So, we may have uncessfull projects with bad messages, or programmers that learn how to write good messages with sucess. None of the options are that bad.

Also, it is not because of the contents of the error messages that users don't read them. It is because on Windows there are so many messages.(And, by the way, that is changing, mainly because Windows userland is getting dominated by FOSS.) People were quite fast to learn to read DOS messages at the time, and ask for help everytime they didn't understand one of them (because they were badly written). That happened because DOS software had the habit of only displaying messages before actions that could be very damaging. Linux display even less messages on a CLI, but GUI software isn't that stringent.

Re:Windows mentality breeds windows mentality

[ArsenneLupin]

The value of error messages become evident as soon as you need to remotely debug your project,

To a good developer, yes.

what happens as soon as it becomes sucessfull.

Applications may become "successful" due to reasons other than quality (market distortions, sole supplier, etc.)

So, we may have uncessfull projects with bad messages, or programmers that learn how to write good messages with sucess.

And then, we may also have good programmers writing good messages, and then being vetoed by management because "it scares the users".

Re:Lennart is right - the kernel patch is the hack

[TheRaven64]

It's the buzzword-of-the-week init system for Linux. If you've been using Linux for a while, then you will be familiar with the typical pattern for deployment:

1. Someone says 'X is crap / old / poorly understood'.
2. Someone else writes a replacement for X, which claims to be backwards compatible, but isn't really unless you only use a small subset of the features of X.
3. Distributions jump on the new X-replacement and ship it.
4. Everything breaks for six months or so, and users complain.
5. Someone else writes an X-replacement replacement, which is a less mature code base with many of the same problems as X and the original replacement.
6. Go to step 3.

Be careful...

[ywwg]

...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

Re:But But But But Buzt Buut

[DaVince21]

Yes. A first-gen Eee PC will stutter quite a bit, depending on how much you multitask. My lightweight laptop with 2 1Ghz cores is completely fine.

Can't wait to see how this will affect my lil' netbook.

Works for me

[amn108]

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.)

Ubuntu and cgroups

[udippel]

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?

Re:But But But But Buzt Buut

[bluefoxlucid]

Does the ad hominim add homonyms?

Re:If you were looking for an example

[Ash-Fox]

A feature that every other OS has had for 3+ years now?

What feature is that again?

Re:Lennart is right - the kernel patch is the hack

[neiras]

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.

You're exactly right.

[neiras]

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!

Re:Lennart is right - the kernel patch is the hack

[amorsen]

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.

Ubuntu's Code of Conduct

[Artemis3]

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

Really? People think they know more than Linus?

[Zero__Kelvin]

"It wouldn't be a hack in user space if it were built into the shell."

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.

Re:Lennart is right - the kernel patch is the hack

[Wandering Idiot]

Does this go doubly if "x" is actually, y'know, X?

Re:Lennart is right - the kernel patch is the hack

[TheRaven64]

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).

You're just getting old

[Colin Smith]

And cynical...

Welcome to the club :)

 

Bad idea

[amightywind]

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.