Slashdot Mirror
The ~200 Line Linux Kernel Patch That Does Wonders
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.'"
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...
Arch: Friday Not to be one of /those/ people or anything...
Isn't it awesome when a new version of your OS performs *better* than the last one on the same hardware?
# cat
Damn, my RAM is full of llamas.
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.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
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.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
This author takes full ownership and responsibility for the unpopular opinions outlined above.
Why not just compile it yourself?
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 .
My blog
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.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Only 3 years? How can you call that a fair chance? It's not even enough time to compile KDE!! :)
(disclaimer: mostly happy Gentoo user here, but yes, like many other worthwhile things, it can come at a cost, mainly in hopefully unattended compile time, and occasionally, if you want the latest stuff, some user/administrator time as well trying to figure out what the ebuild maintainers were smoking when they did certain things.)
Nonaggression works!
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.
Indeed, I find that Linux has an almost miraculous ability to convert users into developers. I've encouraged several friends over the years to use it, and out of those that have actually done it, most have not just stuck with it but have even surpassed me in some ways. It can take a teenager or young adult who knows barely anything about coding or even much about computers and can turn them into a coder or admin in no time. My theory is that people follow a sort of a path:
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.
Yet Another Tech Blog
(but so much more, including game and movie reviews)
http://yanteb.peasantoid.org
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.