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.'"
Compiling the kernel (Score:3, Funny)
Compiling the kernel isn't a useful benchmark. How well does it deal with running Adobe Air?
Re:Compiling the kernel (Score:4, Funny)
Re:Compiling the kernel (Score:5, Funny)
I used to. For 3 years. But I wanted my time back.
Re:Compiling the kernel (Score:5, Funny)
Wow, I think my K6 pentium clone could compile the kernel faster than that!
Re:Compiling the kernel (Score:5, Funny)
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.
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: (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: (Score:3, Interesting)
Re: (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
Re:Yes, linux could improve. And? (Score:4, Interesting)
Or he is less willing to solve problems than you are. Ever thought of that?
Look, you want easy entertainment, you get a DVD player and a TV. You want to get a bit beyond that, you get a gaming console. You want to run with the Internet, you better be willing to learn how to use a PC.
It never ceases to amaze me how smart my parents can be when I'm not available, and how dumb they can degenerate to when I am. It's not even instant Alzheimers, it's like they suddenly can't even read. Could all that just possibly be... laziness?
Re: (Score:3, Informative)
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 (Score:5, Funny)
recompile the Gentoo kernel using --mph=88
Re:Compiling the kernel (Score:4, Insightful)
Re:Compiling the kernel (Score:5, Informative)
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 (Score:5, Informative)
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 (Score:4, Interesting)
I remember, about 8-10 years ago, how this wasn't the case. It was quite evidently better than Windows in this regard, particularly if you didn't upgrade your hardware on a 2-year cycle (eg. waiting until it died) or tried running on significantly older hardware. Performance, on the desktop, was great. 2.6 seems to have progressively nixed it.
The first time I tried compiling a kernel, I was astounded at how I was still able to play fullscreen 600Mb encoded DVDs (can't remember what they were encoded in, but the quality was decent).
I remember building a kernel in '99-2000 or so on a P133 with 64Mb of RAM (running Stormix). Netscape was still responsive. Switching to a different application did't really take all that long.
These days, Linux performance on the desktop, this regard, is worse than Windows. It's a fucking travesty. Using the anticipatory scheduler helps significantly (or did, until they removed it from the kernel), but it was hardly much more than a stopgap measure.
I am pleased as fucking punch that this is finally 'fixed'. Like, I'm giddy to the point where I doubt I'm going to get any work done today.
Where can I download prebuilt kernels for my distro of choice? Surely someone is building them.
Re: (Score:3, Funny)
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 .
Re:Compiling the kernel (Score:4, Informative)
I also had to walk 10 miles, in the snow. Uphill both ways.
Re: (Score:3, Informative)
To continue:
Baud != bps.
Baud is modulation changes per second, and in each modulation change there may be a representation of one or more bits which means that the modem may be 1200 baud but you got 9600 bps out of it due to the modulation (phase and amplitude of tone)
And the old Telebit Trailblazer modems with PEP protocol - they were fantastic in crappy conditions. Multi-carrier technology so that even if there were interference at least a few got through anyway and the only effect was that the bandwidth
Re: (Score:3)
Eh? 300bps acoustic coupler using a Z80 based computer with 16k RAM and a tape recorder as secondary storage device.
That was interesting times.
And hacking on an ASR33 teletype with a paper roll and punch tape. Been there done that... Errors preserved permanently on the input device (paper roll). Earplugs were recommended.
Re:Compiling the kernel (Score:5, Interesting)
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 (Score:4, Informative)
So no, it doesn't have to be a physical RS232 serial line like in the seventies :-)
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.
Re: (Score:3, Insightful)
Re:Compiling the kernel (Score:5, Informative)
Re: (Score:3, Interesting)
Whatever happened to "nice-ing" processes? Couldn't the menu icon that launches VLC or mplayer or whatever re-nice itself a few negative steps?
Why can't the 'raise priority' rule be changed (Score:3, Interesting)
I know Linux wants to be POSIX compliant, but I don't see any harm in changing nice like so:
1. Store the original nice value of a process in the kernel's process table.
2. Allow priority to be lowered by anybody.
3. Allow priority to be raised by anybody as long as it does not surpass the original nice level.
4. Require superuser to go beyond the original nice level (and reset the saved value if they do).
That would be no more dangerous than the current system, but would allow apps to lower their priority tempo
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: (Score:3, Informative)
You either missed it, or are conveniently "failing to mention it", but the idea was Linus' to begin with, and he wasn't expected such great results. There are reasons why Con's patches we
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:teh snappy!!!! (Score:5, Funny)
Re:teh snappy!!!! (Score:4, Informative)
Or rather, that there are different priorities.
The problem was with finer grained scheduling you wound up sacrificing server performance for desktop responsiveness. Linux does not want to sacrifice performance really.
To be fair I've been using linux on my desktop for over ten years now and even without this patch mostly fail to see an issue.
Re:teh snappy!!!! (Score:5, Informative)
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.
Seriously? OS X has absolutely terrible scheduling. A process that causes some swapping will cause beachballs everywhere and can freeze the windowserver for several seconds (well, the mouse keeps moving, but nothing else does). Hell, I have a FreeBSD VM on my Mac that responds better under load than stuff outside of it does.
Re: (Score:3, Informative)
(well, the mouse keeps moving, but nothing else does).
When that happens - MacOS, Linux or Windows, its usually because the mouse driver is interrupt driven and the mouse cursor is drawn by the video card. So the scheduler generally isn't even involved - the mouse generates an interrupt (pausing whatever task is currently scheduled on the cpu), the interrupt handler reads the mouse coordinates and hands them off to the video card, returning the cpu back to the regularly scheduled process and the video card redraws the location of the mouse on the screen.
Re: (Score:3, Informative)
That's pretty bad. On OS X, you used to be able to kill the system by mmap()ing a large file and touching one byte on each page in turn (I had a nice 10-line C program that would kill the system like this). With 10.5, it's a lot better. The system freezes for a few seconds but then it just becomes really slow, rather than dead.
OS X handles out of memory conditions a lot more gracefully than Linux. When Linux runs out of memory, it kills random processes until it can continue. When OS X almost runs o
windows (Score:2)
"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 (Score:4, Informative)
Was I the only one thinking about Amigas and Alphastations?
Amigas had so much offloading that you could pull the CPU out and still move the mouse pointer.
Distros? (Score:5, Funny)
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: (Score:3, Insightful)
Re:Distros? (Score:5, Informative)
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: (Score:3, Informative)
What's cool is that Arch is actually pretty stable and works well, yet it's pretty bleeding edge (although to be honest this kernel will be in testing, not stable. probably in stable 2 weeks after 2.6.37 is released)
Re:Distros? (Score:4, Informative)
Or whenever YOU choose to install the patched kernel. Freedom at work.
Re:Distros? (Score:5, Funny)
Fuck support contracts. Real men fire up gdb when they see a koops.
Re: (Score:3, Informative)
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.... (Score:5, Funny)
Subjective (Score:2, Interesting)
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
Re: (Score:3, Informative)
alt+tab deals with windows in terms of "most recently used".
ctrl+tab goes to the next tab in "position". ctrl+shift+tab goes to the previous tab in "position". They don't do "most recently used tab".
Wasn't there a desktop friendly scheduler rejected (Score:4, Interesting)
Re:Wasn't there a desktop friendly scheduler rejec (Score:5, Informative)
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 (Score:5, Informative)
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 (Score:5, Informative)
Its explained in the BFS FAQ http://ck.kolivas.org/patches/bfs/bfs-faq.txt [kolivas.org]
Why "Brain Fuck"?
Because it throws out everything about what we know is good about how to design a modern scheduler in scalability.
Because it's so ridiculously simple.
Because it performs so ridiculously well on what it's good at despite being that simple.
Because it's designed in such a way that mainline would never be interested in adopting it, which is how I like it.
Because it will make people sit up and take notice of where the problems are in the current design.
Because it throws out the philosophy that one scheduler fits all and shows that you can do a -lot- better with a scheduler designed for a particular purpose. I don't want to use a steamroller to crack nuts.
Because it actually means that more CPUs means better latencies.
Because I must be fucked in the head to be working on this again.
I'll think of some more becauses later.
Re:Wasn't there a desktop friendly scheduler rejec (Score:5, Informative)
BFS makes the classic trade offs which Linus and almost all others absolutely agree is a bad decision for core inclusion. BFS trades performance for latency. Basically you get really good interactive performance in exchange for massively losses in over all throughput and efficiency. Furthermore, BFS sits on a horribly slippery slope in that the level of *inefficiency* scales wonderfully with core count. Basically, the more cores you add, the more time BFS spends BF*cking around.
Basically BFS only makes sense on single or dual core systems which will primarily be used as a desktop. After that, it better be a dedicated desktop system because compared to the stock kernel, performance is going to royally suck, despite latency being fairly good. But then again, BFS was never really designed to address scalability - its always focused on latency and a superior interactive desktop experience. By most measures it works, but at a heavy cost.
Re: (Score:3, Informative)
At first glance it really seems to improve system responsiveness in regards to user input. However this comes with a giganti
Re:Wasn't there a desktop friendly scheduler rejec (Score:4, Interesting)
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.
Re:Wasn't there a desktop friendly scheduler rejec (Score:5, Interesting)
Actually Linus lost track of many such things because too self centered or ego driven (which happens to most of us when you such success and things to deal with but anyways)
This very patch is a prime example, if it goes *default* in the kernel.
It's a patch that favors *only* Linus's usage of linux: Browse the web while his kernel compiles. Now imagine you start your video from a tty (mplayer blah_1080p.avi) and it takes 95% cpu to be smooth, then you start your browser.. uho.
In BeOS I could^H^H^H *can* (haiku, too) start 5 videos on and old PC, browse the web and:
- the browser is smooth like butter
- the 5 videos are a bit choppy (no miracles but that the point) but they all run at the same speed
Now _that_ is what I want a desktop scheduler to be like.
With more criticism he could see that some would want this auto grouping option, but the majority wouldn't. Now what does that tell us?
It tell us that it's _either_:
A/ Not the best solution (i.e. our scheduler sux)
B/ Grouping should be smarter or more easily configurable (it's currently configurable in the previous kernel version and can do just what this kernel patch does!)
Re: (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:Wasn't there a desktop friendly scheduler rejec (Score:5, Informative)
It's been fairly well documented but you still seem to ignore the reality of what happened.
http://kerneltrap.org/node/14008 [kerneltrap.org]
Read all that then tell me that Linus has an ego here. It seems to me that Linus is the only level headed guy and you're just trying to distort what really happened.
- He choose CFS over SD because SD behaviour was inconstant among users' computers
- Con would argue with people sending him problems rather then accept them as problems with his code
- Linus didn't want code in the kernel that would only work well for certain users
- Linus didn't want code maintained by someone that was so hostile to others' critique
- Linus states that he believes the desktop is an important platform
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: (Score:3, Interesting)
Re: (Score:3, Interesting)
So is Linus a dick?
I'm pretty sure this is a well-known and widely-accepted fact, even by the man himself. This is almost certainly why the submitter quoted him as saying, "Good job." That's unusually high praise coming from Linus.
Re:Wasn't there a desktop friendly scheduler rejec (Score:4, Interesting)
Kernel benchmarks are always a point of contention. But interbench and all the standard benchmarks did show a marked improvement with the CK patchset and the Staircase scheduler.
If Linus didn't really believe it was an improvement, then why did he eventually call on Ingo to write a very similar scheduler?
Linus didn't want to admit he was a jerk who made a flippant personal decision rather than focusing on the best code.
Is this a typo? (Score:2, Funny)
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"
Xkcd knows it (Score:5, Funny)
http://xkcd.com/619/ [xkcd.com]
Isn't it awesome (Score:5, Insightful)
Re: (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.
Re:Isn't it awesome (Score:4, Funny)
The PowerPC owners disagree. The new versions don't perform better in their hardware.
This was always my biggest problem with Linux (Score:5, Funny)
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: (Score:3, Informative)
Ubuntu.
And it'll probably be in Natty Narwhal, which is to be released in April 2011. https://wiki.ubuntu.com/KernelTeam/Specs/KernelNattyVersionAndFlavours [ubuntu.com]
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
If you cut back on the eye candy most distros have in their default desktop environments you'll wipe away any sluggishness. Switching to a simple window manager that doesn't use pixmaps for everything will significantly improve X's performance.
Re: (Score:3, Interesting)
I probably haven't tried nearly as many flavors of Linux or Windows as you, but my experience has been the complete opposite. My Ubuntu install, running Gnome on a pretty average system (3.1ghz dual core AMD CPU, 4GB RAM, integrated video), feels lightning-fast and responsive compared to pretty much every other system I've ran so far. Especially the Windows systems I use at work, which admittedly are all XP systems infected with McAfee. I've always been kind of a junkie for really responsive UIs - it drives
Re: (Score:3, Interesting)
Nope, you're not a troll. I have the exact same complaint about Linux desktops (and OSX): Windows just seems slightly but noticeably snappier for keyboard and mouse events. I just thought that someone at MS realized that this was an important area to get right, while Linux and OSX struggled against a cap dictated by other design decisions (such as Apple's Quartz library being strongly based in NextStep's display PostScript origins).
It was never a huge deal to me because so many other considerations are al
Re: (Score:3, Interesting)
Not the mod, but I can see where he's coming from. I can maybe see his claim having merit if he's only tried the heaviest GNOME or KDE distros, but "no matter how many distros he's tried?" That comes very close to trolling, considering there is at least one fairly well-known distro that loads itself entirely into RAM.
Of course it is difficult to argue against anecdotal evidence, especially if you don't know the hardware situation. Personally I'm fairly positive my nicely-tuned Arch install runs circles a
Re:This was always my biggest problem with Linux (Score:4, Funny)
tired "inb4" bullshit...
why?
Because if you can predict how people are going to react to a certain set of conditions then you have demonstrated mastery over their inferior minds. But you have to call it out, or else no one will know!
Re: (Score:3, Interesting)
Yeah, I never really figured it out. These are local directories having, oh, maybe three or four thousand files. It is the first time the directories have been opened since the files were written. But still, what the heck is taking 93 seconds? When I re-open the directory, it only takes a short amount of time, so I figure Windows is creating some kind of cache that first time. Still, it's an inexcusable user experience. But, it's an ongoing problem that I have every day or two, because I deal with a lot of
Re: (Score:3, Informative)
Windows is so annoying with the sidebar thing if you click a video and then try to delete it it won't let you delete it because it's caching the preview for the sidebar.
Seriously? (Score:3, Interesting)
I've been a Windows user since Windows version 1.01 (that used real mode DOS, and text based graphics). Windows has never, ever, ever been "snappy". At least not out of the box. There used to be third-party utilities (eg Norton Desktop), that made the experience better. But, it does depend on what you use it for. If you don't have tens of thousands of files to maintain, and only use it to watch pr0n and for email, and that Christmas letter. Then yes, you will probably have snappy performance.
If however you
backport? (Score:3, Insightful)
Re:backport? (Score:5, Insightful)
Re: (Score:3)
Why not just compile it yourself?
See above [slashdot.org]
Re: (Score:3, Funny)
Because it'll slow down everything on his system...
Actually that sounbds quite large. (Score:4, Informative)
Re: (Score:3, Informative)
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.
Re: (Score:3, Funny)
Re:Actually that sounbds quite large. (Score:5, Informative)
No, you went wrong by confusing "improving the decisions of the scheduler, so that the user experience is improved" with "making the scheduler run faster."
But what if the "heavy background task" has been l (Score:4, Interesting)
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 (Score:4, Interesting)
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)
will this help with the swap-paralysis problem? (Score:5, Interesting)
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: (Score:3, Interesting)
or, plan B: (Score:4, Interesting)
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.
Re: (Score:3, Informative)
I believe the parent is talking about the iowait bug #12309 [kernel.org], which, maddeningly, has nothing to do with swap, or filesystem type. You can turn off the swap entirely and still trigger the bug. Of course there are use cases where heavy swapping brings the system down, so there is a perceived improvement by most people when turning off the swap.
Re:or, plan B: (Score:5, Informative)
Actually even with no swap you will jam Linux when you run out of memory. Things like system libraries get thrown out of memory cache, but are soon needed again and read from the disk. This kind of circus can go on for half a hour until the actual OOM killer gets into the game.
Re: (Score:3, Interesting)
That actually makes a lot of sense, but I've never heard this explanation before. It also seems relatively easy to deal with... e.g. keep a "reload count" and if things being flushed from the memory cache are immediately reloaded, invoke the OOM. Or, the VM system is swapping the wrong things out. Your explanation also makes perfect sense in that I've observed it has nothing to do with swap or filesystem type.
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: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.
But 400 lines of code.... (Score:5, Funny)
....would make it 2x faster! LOC is the #1 metric for programming.