×

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!

The ~200 Line Linux Kernel Patch That Does Wonders

CmdrTaco posted more than 3 years ago | from the well-isn't-that-special dept.

Linux 603

An anonymous reader writes "There is a relatively miniscule patch to the Linux kernel scheduler being queued up for Linux 2.6.38 that is proving to have dramatic results for those multi-tasking on the desktop. Phoronix is reporting the ~200 line Linux kernel patch that does wonders with before and after videos demonstrating the much-improved responsiveness and interactivity of the Linux desktop. While compiling the Linux kernel with 64 parallel jobs, 1080p video playback was still smooth, windows could be moved fluidly, and there was not nearly as much of a slowdown compared to when this patch was applied. Linus Torvalds has shared his thoughts on this patch: So I think this is firmly one of those 'real improvement' patches. Good job. Group scheduling goes from 'useful for some specific server loads' to 'that's a killer feature.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

603 comments

Compiling the kernel (2, Funny)

suso (153703) | more than 3 years ago | (#34241136)

Compiling the kernel isn't a useful benchmark. How well does it deal with running Adobe Air?

Re:Compiling the kernel (3, Funny)

spiffmastercow (1001386) | more than 3 years ago | (#34241144)

Obviously you're not running Gentoo.

Re:Compiling the kernel (5, Funny)

suso (153703) | more than 3 years ago | (#34241154)

I used to. For 3 years. But I wanted my time back.

Re:Compiling the kernel (-1, Redundant)

MrHyd3 (19709) | more than 3 years ago | (#34241172)

I couldn't help but *cough* and *laugh* at same time. Oh so true.

Re:Compiling the kernel (5, Funny)

Albanach (527650) | more than 3 years ago | (#34241646)

I used to. For 3 years.

Wow, I think my K6 pentium clone could compile the kernel faster than that!

Re:Compiling the kernel (2, Informative)

digitalhermit (113459) | more than 3 years ago | (#34241718)

I know exactly what the problem is. Try passing different elevator options to the kernel at boot time. It helps with clock skew on virtual environments.

Re:Compiling the kernel (0)

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

obviously you're not a golfer

funny, haha (-1, Offtopic)

toby (759) | more than 3 years ago | (#34241896)

But compiling the kernel is the one area where Gentoo is exactly the same as every other distribution.

Re:Compiling the kernel (5, Informative)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#34241292)

They aren't compiling the kernel to see how long it will take(which, as you say, is rarely of all that much interest, few people do it and a fast build-box isn't going to break the budget of a serious project), they are using a multithreaded kernel compilation as an easy way to generate lots of non-interactive system load to see how much that degrades the performance, actual and perceived, of the various interactive tasks of interest to the desktop user.

This isn't about improving performance of any one specific program; but about making a reasonably heavily-loaded system much more pleasant to use. Compiling the kernel is just a trivial way to generate a large amount of non-interactive CPU load and a bit of disk thrashing...

Re:Compiling the kernel (5, Informative)

morgan_greywolf (835522) | more than 3 years ago | (#34241894)

Yep. For those that haven't tried it without the patch, a multithreaded kernel compile will typically peg a modern multicore CPU at 100% and will even give you drunken mouse syndrome. Just being able to scroll around a browser window while doing a lengthy make -j64 is impressive. Being able to watch 1080p video smoothly is ... astounding. Especially when you consider the minimum CPU requirement for 1080p H.264 playback is a 3 GHz single core or a 2 GHz dual core.

 

Re:Compiling the kernel (4, Interesting)

laffer1 (701823) | more than 3 years ago | (#34241316)

Compiling the kernel doesn't prove true userspace improvements, but it does show an improvement with scheduling.

I see. It creates "groups" based on the tty and then tries to even out the CPU utilization between groups. This helps if there is a crazy background process eating up CPU and it might even help control flash crushing system performance a bit.

Re:Compiling the kernel (2, Interesting)

ArsenneLupin (766289) | more than 3 years ago | (#34241550)

It creates "groups" based on the tty and then tries to even out the CPU utilization between groups.

Works fine if there are groups than can be distinguished by tty (such as the kernel compilation which has one, versus most interactive apps, which don't, or have a different one).

But it won't necessarily work if the task creating the load is also a ttyless GUI task (such as programs such as dvdstyler)

Re:Compiling the kernel (4, Insightful)

arivanov (12034) | more than 3 years ago | (#34241622)

The answer is very very very badly.

This is a "NERD Feature" patch which does very little to the improve the way Joe Average Luser uses his desktop. In fact it leads to some seriously goofy allocation artefacts.

What it does (if I read it right) is that it puts all processes with the same controlling TTY into the same group. Well, anything launched in X has no controlling TTY. So it all gets lumped into one group. Now you open a xterm and you launch something from there. Miracle, halleluyah, that actually got into a separate schedule group which can now hog a CPU while the rest of apps will fight for the other one on a two core machine. So what am I supposed to do? Start every one of my X applications from a different Xterm so they have a different controlling TTY (and do not close any of them)?

Screw that for laughs.

Process grouping is too difficult to be done based on such simplistic criteria. It is best to provider an interface through which a user can group all of the processes with his UID and leave the Desktop environment do the grouping. Or put something on the dbus which listens and follows who talks to whom to do the same. This will provide much better results than putting yet another simplistic euristic in the kernel.

Re:Compiling the kernel (1)

suso (153703) | more than 3 years ago | (#34241696)

So what am I supposed to do? Start every one of my X applications from a different Xterm so they have a different controlling TTY (and do not close any of them)?

Screw that for laughs.

Don't you use twm?

Re:Compiling the kernel (1)

visualight (468005) | more than 3 years ago | (#34241748)

I'm right with you after reading this, it does seem too simplistic and intuitively I think it would 'get it wrong' too often. But the people who have actually tested this patch seem to love it so I'm going to reserve judgment until I've experienced this myself.

If what you say is true, that I would need to start every task from a shell and keep it open, I think I could manage that very well with yakuake.

Re:Compiling the kernel (1)

Runaway1956 (1322357) | more than 3 years ago | (#34241720)

What the other guys have all said. Compiling the kernel wasn't MEANT to be any kind of a benchmark. The idea is to load the system - notice that they were also playing back a movie WHILE compiling, and they were still able to do meaningful work with yet more windows. Basically, we're talking about the sort of improvement that one used to see when he upgraded from insufficient memory to enough memory to do all the work he requires to be done. Multi-tasking. My machines all run BOINC, full time. Thanks to rather poor scheduling, I find myself waiting for the system, sometimes. This patch should solve that little problem. Make full use of the cores, make full use of all the CPU cycles, but ensure that the system is RESPONSIVE!!!

teh snappy!!!! (5, Insightful)

schmidt349 (690948) | more than 3 years ago | (#34241148)

Considering that UI lag was always my big problem with anything Linux-based (hell, it even seems to affect Android phones), this might be one small patch for the kernel, one giant leap for userspace...

Re:teh snappy!!!! (1)

mcvos (645701) | more than 3 years ago | (#34241674)

I agree. From what I understand, scheduling has always been an issue for Linux, and no solution was ever good enough to be accepted. I'm glad we're finally seeing a big move forward here.

Re:teh snappy!!!! (1)

jellomizer (103300) | more than 3 years ago | (#34241710)

Now is it too late?
Probably not for android phones. But the UI choppiness has been a real barrier to desktop performance and acceptance.

I know some people are touting this as proof that open source works (We saw a problem and we fixed it!). But the fact that Windows and OS X and many other lesser OS have fixed this problem years ago could also be used to show that Open Source is not quite as up on the times as you would like to think.

windows (1)

think_nix (1467471) | more than 3 years ago | (#34241184)

"windows could be moved fluidly"

Damn was I the only one thinking about migrating virtual machines from one box to another , until I read it twice ?

Damn, I need a vacation :)

Re:windows (0, Offtopic)

CarpetShark (865376) | more than 3 years ago | (#34241382)

Was I the only one thinking about Amigas and Alphastations?

Re:windows (0)

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

Was I the only one thinking about Alpacas and Aquaman?

Hmm...Okay then.

Re:windows (-1, Offtopic)

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

Was I the only one thinking about Natalie Portman?

Distros? (4, Funny)

SIGBUS (8236) | more than 3 years ago | (#34241228)

Of course, how many years from now will that filter into the distros? My guess:

Gentoo: soon
Debian Unstable: 2Q 2011
Ubuntu, Fedora: 1Q 2012
Debian Stable: 2015
RHEL: 2020

Re:Distros? (5, Informative)

Ltap (1572175) | more than 3 years ago | (#34241328)

Arch Linux: Already in core.

I exaggerate, but it's not far from the truth - the kernel releases are imported into the testing repository as soon as they come out.

Re:Distros? (0)

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

No one wishing to contribute a PPA for Ubuntu? Puh-leaze...

Re:Distros? (2, Informative)

Kjella (173770) | more than 3 years ago | (#34241464)

If you don't care about having it in a release, then the kernel team already has a PPA with all the releases + rcs + daily builds. I would think the next *buntu release (11.04) will have 2.6.37, so you probably won't see this in an official release until october next year...

Wait.... (5, Funny)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#34241230)

That's not a kernel patch... That's a bash script that forcibly installs BeOS!

Re:Wait.... (1)

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

I wish I had mod points for this one. Freaking hilarious. It's amazing how far ahead BeOS was in regards to smooth multitasking and media handling. Only OS I've seen do better was nextstep/mac os x ...

Re:Wait.... (1)

oldspewey (1303305) | more than 3 years ago | (#34241658)

I remember using BeOS R5 to access files or CDs that couldn't be opened using any other operating system known to mankind.

Subjective (2, Interesting)

falldeaf (968657) | more than 3 years ago | (#34241232)

I guess it's somewhat objective and dependent on your hardware anyway but even with lots of programs open on my main machine I don't notice any slowdown... I think if linux is really gonna pull ahead of the pack they aught to take a gamble on a new, useful interface. Something like 10gui [10gui.com] . The risk could even be mitigated by having a choice to load either type of desktop at the beginning with a quick video to demonstrate the difference. :)

Re:Subjective (1)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#34241568)

Who is "they"? Any recent Linux kernel should be able to support a device such as that shown in the video with a userspace libUSB driver, no modification required. X might take some poking to get it to accept the existence of 10 cursors; but that is a totally distinct project. Then, of course, you have the zillions of programs that are going to need to do something useful with those exotic inputs...(and reasonable availability of that hardware device, and some place to put it along with your keyboard).

It is arguably a weakness of Linux; but there isn't really any "they" to do that. Anybody could; but there isn't really anybody in a position to.

Re:Subjective (1)

falldeaf (968657) | more than 3 years ago | (#34241668)

By 'they' I mean a distro, like Ubuntu for instance. If 10gui eventually comes up with their own window manager (I'm not sure how they plan to distribute or implement their desktop idea.) Ubuntu could let you choose between it and a more standard one like Gnome the same way you can decide between gnome or kde. Also though, the 10gui concept does change the interface pretty dramatically, the concept would work for any program out there out of the box. In fact, if you use one of wacom's bamboo devices which are already available you'd have the benefit of pen input for fine grain control in artsy applications.

Wasn't there a desktop friendly scheduler rejected (3, Interesting)

Culture20 (968837) | more than 3 years ago | (#34241236)

I thought a few years ago, there was a desktop friendly scheduler rejected because Linus thought the server environment was more important. The details escape me.

Re:Wasn't there a desktop friendly scheduler rejec (0)

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

Linux scheduling is a complete mess these days. Too many pissing contests and valid needs for different loads requirements on various platforms. The biggest loss is IO, particularly those with SSD systems when you have to spend two days researching umpteen tweaks get back to the IO performance available 3 releases ago, if you're lucky.

Re:Wasn't there a desktop friendly scheduler rejec (1)

tenchikaibyaku (1847212) | more than 3 years ago | (#34241346)

You thought wrong. Well, the part about a scheduler being rejected is pretty right I guess.

Re:Wasn't there a desktop friendly scheduler rejec (4, Informative)

rwa2 (4391) | more than 3 years ago | (#34241388)

They mention the "Con Kolvias" scheduler in TFA, but they don't seem to want to refer to it by its real name:

http://en.wikipedia.org/wiki/Brain_Fuck_Scheduler [wikipedia.org]

It doesn't scale well past 16 cores, which is why Linus doesn't want to include it in the main kernel. But it's included in custom kernels for mobile devices, such as CyanogenMOD for my Android phone.

Re:Wasn't there a desktop friendly scheduler rejec (0)

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

It doesn't scale well past 16 cores, which is why Linus doesn't want to include it in the main kernel.

What kind of reason is that? If there are =16 cores use it; otherwise, use the old one.

Re:Wasn't there a desktop friendly scheduler rejec (5, Informative)

tenchikaibyaku (1847212) | more than 3 years ago | (#34241514)

This is not the scheduler that the grandparent would be referring to though. BFS has been around for about a year, and has as far as I know never actually been pushed for inclusion.

The previous scheduler that Con wrote was rejected in favor of CFS which is currently in use by the kernel. CFS is at least partly based on ideas from Con, and he was also credited for them.

Re:Wasn't there a desktop friendly scheduler rejec (0, Offtopic)

Culture20 (968837) | more than 3 years ago | (#34241846)

Ah, thanks. Good to know I'm not senile yet. I can haz memory?

Re:Wasn't there a desktop friendly scheduler rejec (1)

GF678 (1453005) | more than 3 years ago | (#34241672)

I've always wanted to know why Con gave it the name that it has. It certainly grabs attention, but does it reference anything or is it just a use of profanity for no purpose?

Re:Wasn't there a desktop friendly scheduler rejec (4, Interesting)

Enderandrew (866215) | more than 3 years ago | (#34241704)

Con Kolivas worked on his staircase scheduler and various performance patches for years. They were routinely demonstrated to be a major improvement. Linus kept saying he was concerned the tradeoff of desktop performance would come in other environments, even though that wasn't true.

Since benchmark after benchmark showed staircase was vastly superior to what was in mainline, Linus then went to go after the guy rather than the code. He said Kolivas couldn't be trusted to support his code, and thusly it would never be accepted mainline. Reality was that Kolivas had been responding to criticism and updating his patchset for over 3 years, constantly improving it. In addition to the LKML, he also maintained his own support mailing list.

I'm a Linus fan 95% of the time, but it was a really shitty move, and it drove Kolivas away from contributing. He quit coding for a while. Then after Linus argued for years how this was a bad idea, suddenly the mainline kernel developed the Completely Fair Scheduler overnight, which was very similar to Kolivas' Staircase scheduler. Linus never admitted he had been a dick for years arguing against the thery of the scheduler rewrite. He then pushed the brand new, untested scheduler into mainline.

CFS is better than what we had before, but it still lost in benchmarks to Staircase, and it was new, untested code.

Now, Kolivas came out of retirement with a new scheduler called Brainfuck that is even faster, but he has no intention of ever tryint to get it in the mainline kernel.

Linux desktop-user-adoption focus groups? (0, Offtopic)

h00manist (800926) | more than 3 years ago | (#34241238)

Is there some place that conducts desktop user focus groups, market studies, etc, on how to increase Linux desktop acceptance? Does anyone publish these results. I participated in a few market-study projects, and although I don't really like these techniques for increasing the sales of detergent, I admit they are awfully effective for understanding what the user thinks of and wants. The ideas that guru techs have of user needs are evidently going to be different than the conclusions that direct observation of user comments by usability engineers, psychologists and anthropologists.

Obligatory meme (-1, Redundant)

Reality Master 301 (1462839) | more than 3 years ago | (#34241244)

Maybe 2011 will finally be the year for linux on the desktop?

Linux desktop users (1)

h00manist (800926) | more than 3 years ago | (#34241300)

Unfortunately it's actually been falling. It was at 1% but it's been going down. Perhaps Android is going to change that. It's not standard Linux, but then again Linux hardly has much of a standard.

Re:Linux desktop users (0)

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

1% of reporting cookies you mean. pffft, hitslink.

Is this a typo? (2, Funny)

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

Is this a typo?

"... slowdown compared to when this patch was applied." - Shouldn't that be something like "... slowdown compared to the performance before the patch was applied"

Isn't it awesome (5, Insightful)

bcmm (768152) | more than 3 years ago | (#34241344)

Isn't it awesome when a new version of your OS performs *better* than the last one on the same hardware?

Re:Isn't it awesome (2, Insightful)

LanMan04 (790429) | more than 3 years ago | (#34241440)

Isn't it awesome when a new version of your OS performs *better* than the last one on the same hardware?

It sure is. Mac OS X has been doing this for almost a decade.

Re:Isn't it awesome (0)

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

Except the latest OS X won't run at all on older hardware.

Re:Isn't it awesome (1)

redJag (662818) | more than 3 years ago | (#34241678)

I love Mac OS X, but let's be honest. 10.1 to 10.4 they were really just fixing performance from the extremely sluggish beta OS. Since then, I haven't seen much improvement personally, while continuing to buy new hardware. It's not a bad thing - they are adding new features without making the OS feel bogged down by them. Also, much improvement has been seen in the past 6 months on the gaming side of things as well.

Re:Isn't it awesome (0)

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

It sure helps a lot if the system you're starting out with is a Petri dish of bugs and a complete hog, like 10.0 was, rather than something like the current linux kernel. :>

Re:Isn't it awesome (2, Insightful)

nschubach (922175) | more than 3 years ago | (#34241446)

You should clarify that you also don't have to do a full reformat, re-install, and get used to the "new" methods for getting to your files.

Re:Isn't it awesome (0)

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

Yeah, that's why I enjoyed both Vista and 7 on my machine. Had 2-5 FPS increase every time.

Re:Isn't it awesome (0)

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

Isn't it awesome when a new version of your OS performs *better* than the last one on the same hardware?

In an attempt to compare apples to apples... if you upgraded only the kernel, and didn't include any fancy new window managers and so forth, this would be true of every commercial OS.

This was always my biggest problem with Linux (5, Funny)

dselic (134615) | more than 3 years ago | (#34241396)

No matter how many different flavors of Linux I installed, it just never seemed as snappy as Windows. There was always a sluggishness about it, nothing I could really put my finger on, but it was definitely there and it bothered me. I'm very glad to hear that a solution is in sight.

I hope the people at Ubunto get this out as an update as soon as possible.

Re:This was always my biggest problem with Linux (0, Redundant)

electrosoccertux (874415) | more than 3 years ago | (#34241484)

*in before someone claims their linux experience was always faster than Windows*

Re:This was always my biggest problem with Linux (3, Interesting)

Jorl17 (1716772) | more than 3 years ago | (#34241560)

As strange as it may seem, I get that feeling when I touch a *used* Windows machine. No matter who used said machine, it eventually starts slowing down to a crawl. When I came to Linux, I came because I wanted a programmer-friendly environment (The Way It's Meant To Be) and I liked Compiz-Fusion (go figure!). Now I run GNU/Linux because it is GNU/LInux -- Free and Open-Source --, with openbox, fbpanel, pcmanfm, gnome-terminal, evince, chromium-browser, LibreOffice, amarok1.4, gedit, vim and some games (some via Wine). By leaving gnome itself, I learned what speed was really all about. However, I can't help noticing that my laptop gets quite a usability hit when I start eating of its CPU(s) -- but when I compare that with the Windows machines under a heavy load, I see that my poor 500€ laptop can top the asses out of those 1500€ lean-mean-Windows-machines. So, I may be an exception, but Linux, for me, in spite of some notorious disadvantages, can still top Windows in terms of these load-related tasks.

Re:This was always my biggest problem with Linux (1)

dselic (134615) | more than 3 years ago | (#34241898)

I know what you mean. Windows really suffers from a bad case of OS rot, a condition exacerbated by the copious amonts of malware collected by the typical user. But the UI, in my experience, is a tad snappier. That's all I was saying.

Re:This was always my biggest problem with Linux (2, Interesting)

dselic (134615) | more than 3 years ago | (#34241758)

Nice to see somebody thinks I'm a troll.

You know, I'm as pro-open source as the next guy here, but I try not to be dogmatic about it. I've played with a bunch of Linuxes from the first half of the 1990s onward and even used it professionally for a time. While there are many things I like about the OS, it does have it's faults. Like not being as user friendly as Win. Like not being as snappy as Win.

I'm really sorry if I hurt somebody's precious feelings, but a troll I certianly am not. And like I said, I'm very glad this patch is coming out and will continue to run Linux as my secondary OS.

backport? (2, Insightful)

real_smiff (611054) | more than 3 years ago | (#34241416)

any chance of backport of this e.g. to .35 kernel for use in ubuntu maverick? i could use that :) or even to .32 for use in 10.04 LTS..

Actually that sounbds quite large. (4, Informative)

91degrees (207121) | more than 3 years ago | (#34241426)

Typically when you get this sort of speedup, it's by rewriting a tiny piece of code that gets called a lot. Sometimes you can get this sort of thing from a single variable, or for doing something odd like making a variable static.

Re:Actually that sounbds quite large. (1)

ais523 (1172701) | more than 3 years ago | (#34241602)

I'd be very surprised if nobody had profiled the Linux kernel to look for all such speedups already. This is likely, instead, one of those speedups obtained via changing to a better algorithm, which can be even better than those made by optimising inner loops. (Speedups from optimising inner loops are generally around 30 to 50 percent unless you did something really stupid, in my experience; I've known speedups from improving algorithms to be well over 10000 percent (or 99 percent, depending on what you measure it relative to).)

Re:Actually that sounbds quite large. (2, Informative)

mcvos (645701) | more than 3 years ago | (#34241860)

From what I gather (which isn't a lot, mind you), it's not so much optimizing the execution of an algorithm, but changing what the algorithm actually does. In this case: smarter scheduling.

But what if the "heavy background task" has been l (4, Interesting)

ArsenneLupin (766289) | more than 3 years ago | (#34241428)

The patch being talked about is designed to automatically create task groups per TTY in an effort to improve the desktop interactivity under system strain.

I guess this works because the task loading up the machine will have been launched from a konsole, and thus be tied to a specific tty (the make -j64 example given later), so a tty-based scheduler can appropriately downgrade it.

But what if the "loading" task has been launched directly from the GUI (such as dvdstyler)? It won't have a tty attached to it, and will be indistinguishable from all the other tty-less tasks launched from the GUI (such as the firefox where you browse your webmail), or worse, Firefox itself creating the load (such as happens when you've got too many Facebook or Slashdot tabs open at once...)

Re:But what if the "heavy background task" has bee (1)

nschubach (922175) | more than 3 years ago | (#34241506)

Someone can correct me if I'm wrong, but a TTY includes the separate terminal sessions and particular X Windows session(S) you are in. IE: CTRL+ALT+F1 - CTRL+ALT+Fn

Not "in window" terminal sessions alone.

Re:But what if the "heavy background task" has bee (4, Interesting)

ArsenneLupin (766289) | more than 3 years ago | (#34241604)

My point is that tty-based scheduling works fine if both groups among which you want to distinguish have a different tty.

With make -j64, this is ok: The make will have been started from a terminal (it's not important whether it's a Linux (console) terminal or within an X window), whereas most other GUI programs won't. So they can be distinguished from each other.

But in case of dvdstyler, it won't have a tty if it has been started directly through the menus, and so the scheduler cannot put it in a different group than all the other GUI apps (which also lack a tty).

Of course, if you start dvdstyler from the command line (from a konsole), this won't apply.

You can easily check which tty (if any) a program has associated by doing a ps auxww and looking at the 7th column (where it will say ? for "no tty" or name the tty (such as pts/9)

Re:But what if the "heavy background task" has bee (1)

headLITE (171240) | more than 3 years ago | (#34241804)

An X session has a tty because it's started on a real tty.
A terminal will create a pseudo tty for everything that runs in it, and if you run make -j64 then make and all its child processes will share that pseudo tty.
A GUI application launched from some X-based launcher will likely not end up with its own tty, but you could start it from a terminal to test if there is any effect.

What this patch does is, essentially, treat make -j64 in a shell as *one* job, not as 64 different jobs that are all equal to your one firefox/thunderbird/glxgears process. I don't think it's the next big thing. But it's certainly an improvement for a situation that is reasonably likely to occur on Linux, whether you know it or not (e.g. the automatic GUI update tool of your distro might really be running some scripts in a pseudo tty, and so on).

Re:But what if the "heavy background task" has bee (1)

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

It'll have a tty attached, but always the same - the one that started Xorg.
You can start GUI apps from the terminal, and they'll keep the new tty (something in /dev/pts), but if you disown them and close the terminal, they'll be tty-less.
At least, this is what I can gather from using "ps -e l"

Fine for me, since besides Firefox I mostly use CLI/curses apps, but it seems it's not a great heuristic for normal GUI users.

typo (2, Informative)

gatzby3jr (809590) | more than 3 years ago | (#34241434)

While compiling the Linux kernel with 64 parallel jobs, 1080p video playback was still smooth, windows could be moved fluidly, and there was not nearly as much of a slowdown compared to when this patch was applied.

shouldn't that read "and there was not nearly as much of a slowdown compared to when this patch wasn't applied"?

will this help with the swap-paralysis problem? (5, Interesting)

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

This has been brought up by others on slashdot before, but Linux tends to be either (A) fine and happy, or (B) pushed into a thrashing state from which it can never recover - like it takes 8 or 10 minutes to move the mouse cursor across the screen. Since there is relatively no warning before this happens, it makes a hard reboot just about the only option.

Will this patch help with that issue? Like the threads below say, once a modern (KDE/Gnome) desktop Linux starts swapping, there is so much new data produced per second by the GUI that it's basically game over. I'd like to see a fix for this: it's the single biggest cause on Linux that makes me do a hard reboot. I just don't have the patients to see if the thing will recover in half an hour or so, even though it might.

http://ask.slashdot.org/comments.pl?sid=1836202&cid=33998198 [slashdot.org]
http://ask.slashdot.org/comments.pl?sid=1836202&cid=33999108 [slashdot.org]
http://www.linuxquestions.org/questions/linux-kernel-70/swap-thrashing-can-nothing-be-done-612945/ [linuxquestions.org]

Re:will this help with the swap-paralysis problem? (2, Interesting)

real_smiff (611054) | more than 3 years ago | (#34241566)

ah i see this regularly on my netbook with 512MB RAM and a slow SSD; just by having too many firefox tabs open. didn't realise it was a known problem. yes very annoying indeed. thanks for bringing it up...

Re:will this help with the swap-paralysis problem? (1)

Skater (41976) | more than 3 years ago | (#34241800)

I did that this weekend by selecting about 150 JPGs on a network drive, then right-clicking and hitting Gwenview. I thought it would load them all into one instance of Gwenview, but instead it loaded 150 copies of Gwenview. D'oh. I think I could have recovered the machine given enough time, but I didn't want to wait and rebooted.

Still, that's only the third or fourth time I've had to reboot a machine for something like that using Linux, and I've been using it since 1998 or so.

I doubt this patch will help with that type of problem though.

or, plan B: (3, Interesting)

ChipMonk (711367) | more than 3 years ago | (#34241878)

Turn off swap, if you can. The cost of memory is now less than the cost of the stress and lost uptime due to swap-paralysis.

I have 4G of RAM on my desktop (I doubled the RAM for $60 after I bought it) and the only time my system swaps is when I have mmap()'ed an 8G file.

Similarly, on my 512M netbook, I don't exceed RAM with crazy things like "make -j64 bzImage". Even with wear-leveling, swapping to SSD is bad form. I'd rather swap over NFS to spinning platters, than to SSD.

Please. (2, Insightful)

drolli (522659) | more than 3 years ago | (#34241454)

When doing benchmarks, do them seriously.

okok... i know its phoronix...

A single *atypical* workload as a benchmark, without a full characterization does not make me consider to use a kernel path on my system which is reported in the style of an UFO-sighting....

I wonder if nicing the kernel compilation would have had a similar effect....

performance on older systems (1)

real_smiff (611054) | more than 3 years ago | (#34241470)

presumably if this helps under heavy cpu load, it may benefit older systems the most? is this true? anyone tried on single core? have read RTFA and they use some i7 thing that i would umm expect to be responsive ;)

Re:performance on older systems (1)

bfree (113420) | more than 3 years ago | (#34241820)

TFA says the videos were from a core i7 but the sentence before that says:

This patch has been working out extremely great on all of the test systems I tried it out on so far from quad-core AMD Phenom CPUs systems to Intel Atom netbooks.

But 400 lines of code.... (5, Funny)

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

....would make it 2x faster! LOC is the #1 metric for programming.

TOO LATE THE HERO !! AND I"LL SING IT TO YOU !! (-1, Offtopic)

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

From the godfather of soul hisself

I hear you had a good offer down on Third Avenue
You tell me that was the reason
For whatcha' put me through, Yeah
And now you come collapsin' back
I feel the heat of your attack
Want me to take you back
I'm givin' you the sack
So don't waste your time

It's a Little Too Little
It's a Little Too Late
I'm a Little Too Hurt
And there's nothin' left that I've gotta say
You can cry to me baby
But there's only so much I can take
Ah, it's a Little Too Little
It's a Little Too Late

You say you had a good time
But did ya' think it was for free - yeah
And how much did it get ya', all their flattery
And now you come back, runnin' for protection
You've been bitten by love and stung by rejection
You can't connect
What did you expect?
I'm still gettin' over you

Normal load? (1)

shish (588640) | more than 3 years ago | (#34241802)

While compiling the Linux kernel with 64 parallel jobs

Ok, but how does it handle under normal desktop stress? Can windows still be moved smoothly when firefox has 50 javascript-heavy sites open?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...