Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Alternative To the 200-Line Linux Kernel Patch

timothy posted more than 3 years ago | from the you-go-first dept.

Red Hat Software 402

climenole writes "Phoronix recently published an article regarding a ~200 line Linux Kernel patch that improves responsiveness under system strain. Well, Lennart Poettering, a Red Hat developer, replied to Linus Torvalds on a mailing list with an alternative to this patch that does the same thing yet all you have to do is run 2 commands and paste 4 lines in your ~/.bashrc file."

cancel ×

402 comments

Sorry! There are no comments related to the filter you selected.

which one is 'right'? (3, Insightful)

vikisonline (1917814) | more than 3 years ago | (#34275876)

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

Re:which one is 'right'? (5, Interesting)

h4rr4r (612664) | more than 3 years ago | (#34275920)

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

Also from the article (5, Informative)

Weaselmancer (533834) | more than 3 years ago | (#34276136)

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. [lkml.org]

Re:Also from the article (5, Insightful)

Anonymous Coward | more than 3 years ago | (#34276536)

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/ [lwn.net]

Re:Also from the article (4, Informative)

by (1706743) (1706744) | more than 3 years ago | (#34276812)

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 (-1, Redundant)

Anonymous Coward | more than 3 years ago | (#34276576)

"There isn't a difference between the kernel patch and the command line hack. They are equivalent."

Except one is user controlled, and the other is forced.

"Linus recommends the kernel patch"

How does this effect servers? 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?

Re:Also from the article (5, Funny)

Anonymous Coward | more than 3 years ago | (#34276734)

How does this effect servers?

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

Re:Also from the article (5, Informative)

SharpFang (651121) | more than 3 years ago | (#34276602)

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 (2, Interesting)

FooBarWidget (556006) | more than 3 years ago | (#34276626)

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 (1, Interesting)

Anonymous Coward | more than 3 years ago | (#34276790)

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 (4, Insightful)

brion (1316) | more than 3 years ago | (#34276948)

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:which one is 'right'? (3, Interesting)

spun (1352) | more than 3 years ago | (#34276028)

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'? (1)

tepples (727027) | more than 3 years ago | (#34276330)

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'? (1)

Carewolf (581105) | more than 3 years ago | (#34276210)

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'? (1)

gilesjuk (604902) | more than 3 years ago | (#34276488)

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'? (0)

Anonymous Coward | more than 3 years ago | (#34276686)

Well, the process given in the link DOESN'T work on FC14. The guy proposing it works for redhat.

mkdir: cannot create directory `/sys/fs/cgroup/cpu/user/19719': No such file or directory

Therefore... the automatic kernel is way is best. No argument.

Re:which one is 'right'? (1)

ehrichweiss (706417) | more than 3 years ago | (#34276956)

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

Any linux kernel? (2, Interesting)

w0mprat (1317953) | more than 3 years ago | (#34275884)

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

Re:Any linux kernel? (2, Informative)

Anonymous Coward | more than 3 years ago | (#34276110)

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

But But But But Buzt Buut (0)

mrmeval (662166) | more than 3 years ago | (#34275886)

H H H how is the stut tering?

Re:But But But But Buzt Buut (-1, Troll)

bonch (38532) | more than 3 years ago | (#34276294)

Why should a user have to bother doing this in the first place just to have a responsive desktop system? Does anyone else see the absurdity of this? Why did it take so long for it to be addressed in the first place?

Just curious what others think.

Re:But But But But Buzt Buut (1)

Gordonjcp (186804) | more than 3 years ago | (#34276370)

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.

Re:But But But But Buzt Buut (0)

Anonymous Coward | more than 3 years ago | (#34276446)

I do plenty of heavy multitasking on my systems (burning CDs while watching hulu (so I'm even using Linux Flash at the same time, which is another supposed issue that I've never seen) while running a minecraft server while someone is playing on that server remotely) and I've yet to see any stuttering. It isn't that great of a system, either (it won't run Crysis properly if I boot into windows for example). This is on a pretty vanilla Ubuntu system from Dell. Is this mostly an issue on old machines or something?

Re:But But But But Buzt Buut (1)

EvanED (569694) | more than 3 years ago | (#34276816)

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 (1)

h4rr4r (612664) | more than 3 years ago | (#34276878)

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

Re:But But But But Buzt Buut (0, Flamebait)

Anonymous Coward | more than 3 years ago | (#34276574)

Why did it take so long for it to be addressed in the first place?

Because nobody noticed that there was a problem. When's the last time you did make -j64?

How does this work? (1)

Manip (656104) | more than 3 years ago | (#34275928)

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? (1)

MichaelSmith (789609) | more than 3 years ago | (#34276016)

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

Re:How does this work? (5, Informative)

greg1104 (461138) | more than 3 years ago | (#34276196)

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 [mjmwired.net] 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? (5, Insightful)

MBCook (132727) | more than 3 years ago | (#34276292)

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 [lwn.net] , 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? (1)

blair1q (305137) | more than 3 years ago | (#34276450)

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? (5, Funny)

sjames (1099) | more than 3 years ago | (#34276944)

Gooooooood make -j64 whatever.

Roll over!

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

Re:How does this work? (1)

Timmmm (636430) | more than 3 years ago | (#34276486)

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

Re:How does this work? (5, Informative)

Corbet (5379) | more than 3 years ago | (#34276736)

Thanks for the nice words about LWN! Here's a special link to the LWN article [lwn.net] 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? (0)

Anonymous Coward | more than 3 years ago | (#34276960)

Corbet, you are not only a gentleman, but also a very shrewd one.

Thanks for the link ;)

Re:How does this work? (1)

BlackPignouf (1017012) | more than 3 years ago | (#34276762)

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?

What's the catch? (1)

TheGoodNamesWereGone (1844118) | more than 3 years ago | (#34275940)

Is there a catch?

Re:What's the catch? (3, Insightful)

Meshach (578918) | more than 3 years ago | (#34275964)

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? (2, Insightful)

Lemming Mark (849014) | more than 3 years ago | (#34276064)

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? (1)

blair1q (305137) | more than 3 years ago | (#34276216)

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? (0)

Anonymous Coward | more than 3 years ago | (#34275968)

Is there a catch?

It depends on whether there was a try.

Re:What's the catch? (1)

c++0xFF (1758032) | more than 3 years ago | (#34276132)

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

Re:What's the catch? (5, Funny)

Monkeedude1212 (1560403) | more than 3 years ago | (#34275976)

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

Re:What's the catch? (5, Funny)

blair1q (305137) | more than 3 years ago | (#34276236)

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

Re:What's the catch? (3, Funny)

Monkeedude1212 (1560403) | more than 3 years ago | (#34276460)

So the 22nd catch is the exception?

Re:What's the catch? (2, Funny)

weirdcrashingnoises (1151951) | more than 3 years ago | (#34276852)

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

Ah the beauty of the interconnected world... (1, Funny)

Anonymous Coward | more than 3 years ago | (#34275952)

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... (1, Informative)

Anonymous Coward | more than 3 years ago | (#34276020)

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

Anonymous Coward | more than 3 years ago | (#34276058)

systemd has just eliminated the use of shell scripts at all, so it's really quite unrelated.

Re:Ah the beauty of the interconnected world... (1)

MichaelSmith (789609) | more than 3 years ago | (#34276036)

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

old-school (2, Funny)

MagicM (85041) | more than 3 years ago | (#34275972)

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

Re:old-school (4, Funny)

Suki I (1546431) | more than 3 years ago | (#34276130)

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 meet olds kool (1)

WillAffleckUW (858324) | more than 3 years ago | (#34276176)

Racing stripes do the same thing and are much prettier.

I find magnets work best of all.

Re:old-school meet olds kool (1, Funny)

Anonymous Coward | more than 3 years ago | (#34276242)

Use the TURBO button!

Re:old-school meet olds kool (0)

Anonymous Coward | more than 3 years ago | (#34276358)

Way back when x86 processors were starting to go faster than 3 MHz, desktops built around these faster CPUs had actual turbo buttons that toggled the machine between standard and fast CPU speeds. This was because some software was built assuming a particular CPU speed. Most software would just run faster if you pushed the turbo button, but some things (particularly a lot of games) would behave weirdly or crash.

GNOME still has a turbo button (1)

tepples (727027) | more than 3 years ago | (#34276434)

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 (1)

h4rr4r (612664) | more than 3 years ago | (#34276540)

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

Re:old-school meet olds kool (0)

Anonymous Coward | more than 3 years ago | (#34276584)

Surely it was an "un-turbo" button, it crippled your 8086 or 80286 back down to the speed expected by certain software, not what the PC was capable of. Incidentally I'm writing this post on the keyboard which came with my 12MHz 286 1MB Decstation PC. A very nice keyboard. The Decstation case was nice but unfortunately not worth salvage. It had 3.5" full height drive bays only.

Re:old-school meet olds kool (1)

h4rr4r (612664) | more than 3 years ago | (#34276692)

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.

Re:old-school (2, Funny)

blair1q (305137) | more than 3 years ago | (#34276466)

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

While the bashrc approach may seem attractive (4, Interesting)

joeflies (529536) | more than 3 years ago | (#34275974)

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 (3, Informative)

Trepidity (597) | more than 3 years ago | (#34276010)

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 [freedesktop.org] , 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 (5, Insightful)

Shimbo (100005) | more than 3 years ago | (#34276494)

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 [freedesktop.org] , 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?".

Seems like a good plan (4, Informative)

Lemming Mark (849014) | more than 3 years ago | (#34276026)

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 [webupd8.org]

The comment here is very important to remember though:
http://linux.slashdot.org/comments.pl?sid=1870628&cid=34241622 [slashdot.org]
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.

4 Lines Is Not All. Let's Not Forget... (1)

mgmartin (580921) | more than 3 years ago | (#34276034)

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.

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

rubycodez (864176) | more than 3 years ago | (#34276168)

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

Re:4 Lines Is Not All. Let's Not Forget... (2, Funny)

blair1q (305137) | more than 3 years ago | (#34276548)

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

Re:4 Lines Is Not All. Let's Not Forget... (4, Informative)

fahrbot-bot (874524) | more than 3 years ago | (#34276994)

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:4 Lines Is Not All. Let's Not Forget... (0)

Anonymous Coward | more than 3 years ago | (#34276306)

Or dig thru the code and figure out what the 1 is turning on and get rid of the conditional and just have it on...?

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

Anonymous Coward | more than 3 years ago | (#34276372)

mounting anything? /etc/fstab, in worst case /etc/rc.local. modifying everyone's .bashrc? i thought there's /etc/profile for that.

Re:4 Lines Is Not All. Let's Not Forget... (3, Informative)

RyuuzakiTetsuya (195424) | more than 3 years ago | (#34276614)

/etc/bash.bashrc

Global bashrc file.

discussion on LKML (0)

Anonymous Coward | more than 3 years ago | (#34276044)

linked here http://lkml.org/lkml/2010/11/16/330

Poettering is pimping systemd (3, Interesting)

Anonymous Coward | more than 3 years ago | (#34276050)

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 (5, Insightful)

Chuck Chunder (21021) | more than 3 years ago | (#34276542)

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 (4, Insightful)

h4rr4r (612664) | more than 3 years ago | (#34276764)

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 (1)

Provocateur (133110) | more than 3 years ago | (#34277016)

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.

Whee... (5, Funny)

Target Practice (79470) | more than 3 years ago | (#34276124)

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

Re:Whee... (3, Insightful)

Pharmboy (216950) | more than 3 years ago | (#34276572)

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... (-1, Flamebait)

h4rr4r (612664) | more than 3 years ago | (#34276788)

Read the same forum and see that had the newb used the forum search he would not have been replied to so rudely. They got support for free, the fact that the person giving it did not have the best bedside manner is the to be expected.

Re:Whee... (5, Insightful)

javelinco (652113) | more than 3 years ago | (#34276984)

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... (5, Insightful)

gandhi_2 (1108023) | more than 3 years ago | (#34276966)

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... (4, Insightful)

bmo (77928) | more than 3 years ago | (#34276978)

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

codepunk (167897) | more than 3 years ago | (#34276972)

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

modW 0p (-1, Troll)

Anonymous Coward | more than 3 years ago | (#34276164)

Outreach are about h4lf of the

Why isn't the good old 'nice' command suitable? (1)

zmedico (565341) | more than 3 years ago | (#34276184)

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? (0)

Anonymous Coward | more than 3 years ago | (#34276278)

I guess the kernel takes a lot of different things into consideration, and just nicing processes won't always have the same effect as whatever they're doing here.

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

Anonymous Coward | more than 3 years ago | (#34276282)

Because 99% of everything on your system runs at 'nice 0'.

CGroups group related entities into a single schedulable object.

So if you have 'mplayer' in one tty, and 'make -j64' in another, instead of the ~70 processes sharing 100% of the CPU at 'nice 0', you have two objects - 'mplayer' at 50% CPU, and 'make -j64' at 50% CPU. The 64 'make's then have to share that 50%.

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

icebraining (1313345) | more than 3 years ago | (#34276474)

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? (0)

Anonymous Coward | more than 3 years ago | (#34276490)

It's sort of like a dynamic nice -- within a group, the more processes you pile in, the more nice each one gets. But as a whole, the group maintains the same priority against other groups.

captcha: harmony

Ubuntu instructions incorrect (4, Informative)

mister_playboy (1474163) | more than 3 years ago | (#34276206)

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 (1, Interesting)

Anonymous Coward | more than 3 years ago | (#34276468)

It's fixed now

What does this do? (1)

adenied (120700) | more than 3 years ago | (#34276248)

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? (4, Informative)

icebraining (1313345) | more than 3 years ago | (#34276566)

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? (-1, Redundant)

Anonymous Coward | more than 3 years ago | (#34276640)

The answer is about 10 replies from the top of this thread. And elsewhere in the thread, I'm sure.

Re:What does this do? (4, Informative)

Tacvek (948259) | more than 3 years ago | (#34276694)

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? (1)

bobbuck (675253) | more than 3 years ago | (#34276964)

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? (1)

tinkerghost (944862) | more than 3 years ago | (#34276702)

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.

DOes it really make any difference (2, Funny)

HelloKitty2 (1585373) | more than 3 years ago | (#34276506)

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

2 Commands and 4 lines!? (1)

rsilvergun (571051) | more than 3 years ago | (#34276800)

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

Following in Windows' footsteps, but backwards (1)

broknstrngz (1616893) | more than 3 years ago | (#34276936)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?