The ~200 Line Linux Kernel Patch That Does Wonders 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.'"
teh snappy!!!! (Score:5, Insightful)
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:Distros? (Score:3, Insightful)
Isn't it awesome (Score:5, Insightful)
backport? (Score:3, Insightful)
Re:Isn't it awesome (Score:2, Insightful)
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 (Score:3, Insightful)
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.
Please. (Score:3, Insightful)
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....
Re:Compiling the kernel (Score:5, Insightful)
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.
Actually understand the benchmark, then criticize (Score:5, Insightful)
Obviously you've never compiled a kernel passing -j64 to the make process. If you had, you would know that all your CPUs would be pegged (indeed -j7 pegs all 8 cores on my laptop.) Of course that is not the benchmark part. The point is that with an "all your processors are belong to kernel build" condition, group scheduling allows there to be essentially no perceived slowdown for interactive GUI/Window manager based computing. You probably should have figured out that you were missing something when Linus Torvalds didn't object to the benchmark and the results. Seriously, this is a major point to understand: When it comes to the kernel, in a fight between your knowledge and Linus', Linus wins.
Re:Please. (Score:4, Insightful)
I wonder if nicing the kernel compilation would have had a similar effect....
Probably, but that's not really the point. A user should rarely (if at all) have to use nice on a desktop, because a desktop operating system is supposed to be able to keep input latency low, always. That is the reason BeOS had such incredible perceived speed, but some "modern" operating systems are still struggling with this feat. I mean, it's 2010 and we've had 25+ years to work this out. Cursor stuttering and choppy video should have been a completely solved problem by now.
Re:backport? (Score:5, Insightful)
Re:Compiling the kernel (Score:5, Insightful)
1) There are no 1200 kbps dialup modems. The fastest ones do 56 Kbps under specialized conditions.
2) If you meant to say 1200 bps modems, well, by the Linus wrote and released the first versions of the Linux kernel, 1200 bps modems and the 386SX were both well obsolete. The most common systems of that day were 486DXs running at 33 MHz at the sweet spot and 50 MHz at the high end. Most people had modems capable of greater than 9600 BPS (many around 14.4Kbps and 28.8Kbps)
3) Now quit making fun of us real old-timers and get off my lawn .
10GUI and similar GUIs are overrated (Score:3, Insightful)
The 10GUI interface would just get in my way a lot.
I often have about 30 windows open (I have a double height taskbar) - ssh sessions, browsers for work, browsers for nonwork (e.g. slashdot
Sad to say, I find Windows XP/7 is so far best for handling stuff like that. Even better than OSX.
I tried doing the 30+ windows thing on OSX, using Expose. But it's just slower - more steps to get from one window to another. In contrast, on windows I can just click on the desired task button and that's it, no need for two clicks, or click then pause or other bullshit. Keep in mind, I'm not saying Windows is the best possible, there's still room for improvement. For instance, it'll be nice to be able to "alt-tab" from one browser tab to another browser tab (so much so that sometimes I open new browser windows just to be able to alt-tab between them).
KDE when I last used it was stupid. They sort tasks top to bottom first then only left to right. So if you have a double height taskbar and you close one button in the middle, all the buttons to the right of the closed button change position! That is so stupid.
If you think it's ridiculous to have 30 windows open, keep this in mind - nearly any crappy GUI can seem cool and easy for a workload that only has 3 windows open. It's when you need to juggle lots of tasks at the same time that's where the GUI either adds value or gets in the way. On-topic analogy: it's just like an O/S, a crappy kernel can seem good when you only have 3 concurrent processes. It's when you have 30 concurrent _running_ processes that you find out whether the kernel's IO and CPU scheduling is good, mediocre or poor.
I would prefer a GUI that's good for the naive/noob users, but at the same time provides short-cuts that can speed things up immensely for users that are willing to learn them.
GUI designers should not assume that users are not able to learn "fancy" stuff. Just watch an experienced Starcraft player (actions per second and all that
A great UI should be able to hyper-augment humans. To paraphrase a perlism, a great GUI should make simple things trivial, and difficult things easier.
Desktop GUI designers should not be saying "most people don't do difficult things so let's just handle the simple case".
Re:Compiling the kernel (Score:3, Insightful)
Re:Just say it (Score:5, Insightful)
Occassionally, yes. But usually when Linus flames someone on the LKML he is entertaining, and is right. This was an instance where Linus just seemed to be a dick for no reason.
Re:Compiling the kernel (Score:4, Insightful)
Re:Wasn't there a desktop friendly scheduler rejec (Score:3, Insightful)
I think part of the reason that Linus is more accepting of this change rather than replacing the entire scheduler (like Con Kolivas pushed for) is that Linus likes small, neat patches. And I think Linus gets offended when someone wants to rip out large sections of the kernel and replace them.
I often wonder how much old, legacy code there is in the kernel that is just overlooked. Anytime you carry code for that many years, you're bound to have some legacy systems that can due to be replaced.
Re:Wasn't there a desktop friendly scheduler rejec (Score:5, Insightful)
Its been fairly well documented as to what happened. Linus is an egotist; as are many smart people, including others on the LKML. It seems Con has a fair ego himself with somewhat gruff interpersonal skills. The combination put him at odds with a lot of people. Generally speaking, people with large egos, don't like others who know more than they do, especially when its their pet project. Furthermore, Linus already had some people he trusted, who also had their ego's hurt by Con's work.
So the line was drawn. Linus and his trusted lieutenants on one side and Con on the other. Linus with his lieutenants, all with hurt egos from a slightly abrasive developer who clearly understood the problem domain better than all of them, simply decided he preferred his pride and undue ego over that of Con's potential contributions.
Not surprisingly, this type stuff happens ALL THE TIME amongst developers. I can't tell you how many times I've seen personal pride and ego take priority over extremely well documented and well understood solutions. Not to mention, frequently, the same documentation which explains why its a good decision, also explains why the decision of pride is an incredibly bad decision; with a long history of being very dumb. Despite that, egos frequently rule the day. So its hardly surprising that Linus isn't immune.
Re:Yes, linux could improve. And? (Score:5, Insightful)
1. They use a bloated (but more immediately user-friendly) distribution like Ubuntu.
2. They hear about other users with lighter software and try it out. It requires a bit more configuration to be the way they want it to be. In the process, they learn more about their system and they learn many useful things.
3. The drive for improved performance and usability leads them to learning more and more and doing deeper and deeper configuration until they know a great deal and are very comfortable with their system.
4. The "scratch that itch" (ESR) effect comes into play; they see deficiencies in existing software and go out to make their own.
5. Before long, they are contributing to several projects, have a technical blog, and are advanced users.
It seems to be some sort of natural progression and it's interesting to see it happen over the period of several years. More significantly, Linux seems to turn a higher percentage of basic users (even those of the luser variety) into developers and advanced users. This seems to be why Linux progresses at such a fast pace; its users actively encourage other users to involve themselves on a deeper level.
Doable today! No kernel changes required. (Score:1, Insightful)
http://lkml.org/lkml/2010/11/16/330 - user space solution that does the same.
Re:Yes, linux could improve. And? (Score:5, Insightful)
Back in the 80's and 90's many DOS users followed the same path. BYTE, PC Magazine, and even PC Computing provided essays on "how it works" and source listings for 8086 ASM and BASIC programs. But somewhere around the time of Windows 95, things seemed to change and it became expected that the "average user" had no interest or time in learning how anything works. I remember that desire to Not Know Or Care as one of the major friction points between the DOS user base and the Windows (and Mac for that matter) user base.
Re:This was always my biggest problem with Linux (Score:2, Insightful)
I don't want to start a flamewar either, but I'll throw in my two cents. My own experience has been that Windows 95, Windows 98, and Windows 98SE (never really used ME) were snappy on the hardware of their day when it came to things like file browsing. This held true even after the installation of IE4 to IE6SP1 (although after every IE install it seemed less snappy). In comparison, Nautilus, Konqueror, Dolphin, and ROX all seem significantly slower on much more powerful hardware. With Windows 2000/XP on similar hardware I see similar behavior.
I'd assume it's all scheduling issues, personally. But, then, it could also be partially a perceptual thing. A file browser locking up for two seconds and displaying a full file list seems faster (and is less annoying) than a file browser that updates every half second (which is frustrating because things jump around) and displays a full file list after 1.5 seconds (although you'll probably have to wait until 3 seconds to make sure it didn't just seeming stall and will resume again). With Windows 9x, it seemed that whatever you were doing was always more responsive than what happened on Windows 2000/XP or Linux, nearly regardless of the power of the hardware.
It's funny, but Windows 9x came out at the time when hardware was finally powerful enough to have near instant user interactivity on most common tasks, so it's not hard to see why people might have fond and/or warped memories of the past. I know i do.
Re:Yes, linux could improve. And? (Score:3, Insightful)
Part of the problem was the jump in difficulty. Windows 286/386/3.0 was difficult enough to program that to do anything useful required more than just basic skills. Also BAT worked sorta well as a scripting language there no scripting language for windows.
Basically the difficult shot up suddenly when it came down again with things like visual basic the paradigm had changed. Incidentally its still fairly hard in windows to manipulate hardware.
Re:Compiling the kernel (Score:2, Insightful)
For an OS that has been around for nearly 20 years and has had thousands of very bright programmers poring over it, it's quite astounding that only now has someone finally figured out how to let gui-related activity have top priority.
Re:Yes, linux could improve. And? (Score:3, Insightful)
I have to say that I went rougly the other way: I started with Linux because I was highly discontent with the then-current Microsoft offerings, finding them unwieldy and unstable. I started way back on Slack 6, where the first step of the installation process was compiling your own kernel and gcc three times to get them pure :-)
Later I switched to RedHat (3 or 4, I think), and was also messing in some code - mostly for my own benefit, can't recall ever committing anything because I didn't think the changes I made were useful for enough people to be included.
These days, I just run Ubuntu - I've been through the whole trial-and-error config file thing, it's given me a good understanding of many things, but now I just want something that simply works so I can get on with other stuff.
These days, the MS offerings (well, some of them) are at least a lot more stable, although I personally still find them unwieldy - I guess I'm no longer used to having my OS babysit me. I even occasionally recommend that a friend who needs a reinstall sticks with windows, depending on his needs, although I always offer them Linux, too. I flat out refuse to support windows boxen, though :)