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.'"
Compiling the kernel isn't a useful benchmark. How well does it deal with running Adobe Air?
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...
"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 :)
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
Oh, no! You have walked into the slavering fangs of a lurking grue!
That's not a kernel patch... That's a bash script that forcibly installs BeOS!
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. 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. :)
check out the Mp3 Garbler I built!
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.
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.
Build your own energy sources from scratch. http://otherpower.com/
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"
http://xkcd.com/619/
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
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.
Build your own energy sources from scratch. http://otherpower.com/
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.
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.
You thought wrong. Well, the part about a scheduler being rejected is pretty right I guess.
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
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.
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.
Auto group scheduling is useful for servers too.
Dilbert RSS feed
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..
This is my Sig, this is my Gun. One is for Slashdot and one is for Fun.
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.
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...)
shouldn't that read "and there was not nearly as much of a slowdown compared to when this patch wasn't applied"?
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
http://ask.slashdot.org/comments.pl?sid=1836202&cid=33999108
http://www.linuxquestions.org/questions/linux-kernel-70/swap-thrashing-can-nothing-be-done-612945/
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....
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 ;)
This is my Sig, this is my Gun. One is for Slashdot and one is for Fun.
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.
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.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
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.
....would make it 2x faster! LOC is the #1 metric for programming.
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)
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?
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.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
It'll have a tty attached, but always the same - the one that started Xorg. /dev/pts), but if you disown them and close the terminal, they'll be tty-less.
You can start GUI apps from the terminal, and they'll keep the new tty (something in
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.
Dilbert RSS feed
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?
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
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).
Ah, thanks. Good to know I'm not senile yet. I can haz memory?
this is 'strong shit' ?
Read radical news here
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.
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
Many terminal emulators include the option of creating or not creating a TTY to attach to when you run them.
Start a terminal and type w. You might find a pts terminal for each terminal you are running.
It's actually north of 10%. Lots of users dual boot and many larger businesses use Linux on the desktop too.
and confused replies routinely get interpreted as unfunny sarcasm and moderated down as Troll or Overrated.
How do replies with extremely long, boring and pedantic "corrections" of obvious jokes fare?
Comment of the year
Community firmware on devices with a digitally signed kernel or with oddball hardware for which the community can't figure out how to write a driver: Never.
Community firmware and Google apps (including Market) on the same device: Cease and desist.
Community firmware on devices sold in United States retail stores without a bundled $70/mo phone plan: Give me a break.
alt+sysreq REISUB
R: keyboard in raw mode
E: end signal to processes
I: kill signal
S: synch filesytems
U: emergency umount filesystems
B: reboot
So is Linus a dick?
10gui just _looks_ nice to the naive, and probably OK for people who only can cope with a few windows open at a time. But I don't see how it's actually going to be faster in task switching than using alt-tab, or clicking on task bar buttons.
:) ), IM windows, editor, email, virtual box machines, file managers, it all starts to add up. I find opening and closing stuff only to reopen them again is usually a waste of time - why close an app if you're not running out of memory and you can still remember which task button raises it? So if a colleague on IM says: "hey can you restart XYZ again?" I don't have to ssh in, and etc. All I need to do is just click on the correct task button, press up arrow, confirm its what I want, press enter.
;) ) or some other competitive gamer, or watch a skilled person handling a Point-of-Sale machine.
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".
If I remember right, one of Linus' main complaints was that there were no hard numbers to support the fact that CK's scheduler was any better. Users would report that things seemed "less jerky" when using it but there was no test that put a number to this.
Now it seems that a change is going in which makes things seem "less jerky"...
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!)
Obviously they didn't apply the patch to their web server first...
The name is a total misnomer. I mean, it's not ever legal brainfuck code. (I didn't know you could even write kernel modules in BF...)
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
Did anyone else notice in the second video that the window manager was the slowest rendering part of the desktop? By a lot, too. Every other desktop component handled exposures rapidly but the window manager decorations lagged by 50-100ms.
'bout what I've come to expect from gnome stuff.
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.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Well, if it is something trivial use it. I mean 16 core's isn't that uncommon anymore, especially in servers but also desktops are catchin up that limit quite fast.
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.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
See this bug which has made the last 3-4 releases of Ubuntu necessary to reboot daily like Windows ME:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/131094
Its explained in the BFS FAQ http://ck.kolivas.org/patches/bfs/bfs-faq.txt
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.
Really?
I did not know that.
Thank you so much for explaining that.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
had a look at the slashdot tags saying "linux finally slashdotted". moving on to next story.
-- It is the mark of an educated mind to be able to entertain a thought without accepting it. -- Aristotle
...except you do it more often. ;-)
I actually quite like the idea of Gentoo, but I find the actuality of it a bit frustrating. Back in the day, many of us learned about Linux by doing it from scratch but without the modern helpful references, or used SLS/Slackware, which gives you a world to stand on while you compile the stuff that is interesting to you without getting in the way.
LFS (and probably Gentoo) is great for a single-purpose or server system, but for a desktop system the compile-time overhead is just a total waste of time. I often hear the claim that Gentoo is a great way to learn about Linux, but my experience is that most people just follow the cookbook without taking very much in at all.
The year of the Linux desktop can now be scheduled!
well, use libcgroup, it has a daemon which can sort on a lot of stuff. Try it out, its not too hard and does not need a new kernel.
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.
I think it's very easy to understand that an OS with little funding, coded by many underpaid or not-paid programmers, with little status and recognition or prestige, would have some problems. I still consider it a minor miracle that it even exists and is usable at all. The US was once a backwater refuge-colony for Britons, and Australia was only a prison. Yes, Linux has much to improve and grow. It will come with more users, which you and me could help with, being coders or not. You can help with more testing and cool-headed participation in forums, and code translation. Or trying to mediate among disputing parties, which also understandably happens a lot, as in any project involving more than a couple of people. We need to understand the competition is closed-source, or Microsoft - not red hat vs debian vs ubuntu vs netbsd vs freebsd vs openbsd. Yes, making agreements and coordinating thousands of disparate parties is hard, but it's the crux of the matter.
Build your own energy sources from scratch. http://otherpower.com/
I keep seeing your signature and thinking that it is a group of fans of the Honda CB 750 Nighthawk motorcycle. Disappointment soon follows. :(
-molo
Using your sig line to advertise for friends is lame.
Has anyone had any success with daily use of distributed-processing, like Kerrighed, http://www.xtreemos.eu/project, OpenMosix, etc?
Build your own energy sources from scratch. http://otherpower.com/
It's because he implemented in in Brainfuck.
http://en.wikipedia.org/wiki/Brainfuck
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.
That is not what this is at all.
This is extra logic for the scheduler to make smarter decisions about what to run, when. The result is better utilization and a better user experience.
This is completely different from "optimize some inner loop to make it 30% faster". This is "in certain situations, we used to do something stupid, but now we do something less stupid, so overall performance is better."
Slackware users build their own kernels, so we can put it in any time we like.
...laura
Hey now. Don't let facts get in the way of mindless linux bashing in favor of mindless apple fanboism.
Brain Fuck Scheduler, written by Con. I understand there is no marketing effort involved in much of geekdom, but if that is the case, can we call it something less discouraging, even if it's Death Star Linux Kernel Scheduling Accelerator, (this is not cron), by C.Kolvias. This is the first time I read about it that I don't click off to the next topic assuming it's a joke.
Build your own energy sources from scratch. http://otherpower.com/
I have Arch Linux running on an old single core Athlon based machine, and about two months ago I compiled the Arch kernel to use BFS, because I had heard it was good for the type of machine I was using. My experience pretty much agrees with what you're saying here. I wish I would have read something this honest about it before I bothered to set it all up and compile the kernel.
At first glance it really seems to improve system responsiveness in regards to user input. However this comes with a gigantic trade off. As an example: If I had a standard definition xvid file playing, the video would literally pause while the system loaded other programs like Firefox, Nautilus, etc. To me that is unacceptable. User input is nice, but if it's choking the entire rest of the system, it isn't something I want to use. The standard scheduler that comes with the kernel might not be perfect, but it will continue playing video while it opens up other apps.
Ouch. Your experience surprises me. I would have thought BFS would be a great option for an older, single core box, seemingly being used for classic desktop-user activities.
CPU and RAM in most systems have been more than adequate for years. The big bottleneck on desktops is disk speed and to a lesser extent the I/O system bus. I just bought a i7 quad core system with 8 gigs of RAM. Even with next to no CPU or RAM load I can still cause the UI to slow to a crawl and even hang if certain processes are thrashing the disk. Why is this still a problem nowadays? My UI shouldn't even need to touch the disk once the OS boots, it should be residing in RAM at that point so why hang when there is disk load? Is it a software issue with how the OS handles disk I/O or a physical design issue in how the desktop architecture handles it?
Because Linus believed that Ingo would support his code to Linus' standards, and Con Kolivas would not? I mean geez, the least you could do is take him at his word.
Unbelievable. There's always one..
No matter how many different versions of Windows I installed, it just never seemed as snappy as Linux. 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 sad to hear that there's no solution is in sight.
I hope the people at Macrosoft get that out as an update as soon as possible.
You don't want to argue your point, but you're going to give it to us anyway, then run away thinking you have the moral highground. I bet you're an absolute joy to argue with. I guess Linux fans have to pull tricks like that though. BTW, I don't want to argue or start a flamewar.
Who gets to review the code before it is deployed into the wild, anyone can say I have code for the kernel that is good for everyone, what if the governing body on the linux kernel has been asked to add a backdoor for the government, would we know, is there any way of seeing the code before we are to download it???? (newbie linux user)
why upgrade the kernel with gentoo any more often than with any other distro? all portage does, is install sources for the kernel; you are left to do the configure and compile yourself.
As for the "overhead" sleep or go to work during it. I've spent way more time doing video encodes on my desktop than I have doing compiles. Granted I don't have KDE4 installed, or source openoffice, but i like xfce better anyways.
All of the above was encrypted with a Quad ROT-13 method. Unauthorized decryption is in violation of the DMCA.
Hand-carved from meteorites.
And open source software is supposed to be better because...?
Who rated this a troll?
It is funny you pathetic dipshit fanboi
http://lkml.org/lkml/2010/11/16/330 - user space solution that does the same.
Thanks for sharing that blast from the past with us, Grandpa. You can go back to sleep now.
...welcome to the club! Having an OS that "just works" is great, eh?
Now maybe you might get working drivers next year.
who prints what programs have updated /var/run/utmp. This is not the tty that this patch is using. Updating utmp can be skipped for many reasons. Main ones are to just make that output from who shorter, but it also means the terminal emulator does not have to be setuid.
Ha, at least it wasn't as bad as Mac OS 9... where *everything* paused to give the user good interactive performance navigating a *menu bar*. Sheesh. Cooperative multitasking fail.
I got so paranoid trying to learn and use all of the few shortcut keys available (along with their idiosyncrasies) and run through any remaining menus really fast so my computations could keep processing and not grind to a halt for too long.
Seriously, who the hell is dumb enough to run make -j64? That's just BEGGING for your system to slow to a crawl. I have two cpus so like a sane person, I use -j2, and my desktop responds just fine without this patch.
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 temporarily when they go off to perform 'batch-like' processes, restoring it when they return to interactive mode.
Posted from my Android phone. Oh, I can change this? There, that's better...
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 use it for business, and write dozen of documents a day and have millions of lines of code in thousands of files, and are creating videos and music, then you will not see snappy Windows performance. That said, unless you've been using the -ck kernel patch (I downloaded and stored on my own server when CK left in storm), you've not seen snappy performance in any full blown WM in Linux either. Now, it looks like they finally got a kernel patch that can compete with Con's 6 year old patch. Congratulations Linus! It only took you and your crew six years to duplicate the work of one man that you bullied out of the kernel group!
Running Linux since 1991! Wow it's almost been 20 years since I attained enlightenment!
could there be a live swap of scheduler when you switch to init level 5 or something like that.
Ingo is a respected member of the kernel community. Of course he will support his code.
But Linus had no real reason to suggest that Con wouldn't support his code after he had already been doing that for 3 years.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
https://www.archlinux.de/?page=UserStatistics
I use Arch as well. Many people do. And it's tired, almost as much as the over 9000 meme.
As I type this, I'm running a fresh version of 2.6.37-rc2 with the patch applied. Nummy. I'm watching 1080i video on the other monitor, and typing this on the first one. Things *are* more snappy than before! The patch is small, it went in without any hiccups, and there is no waiting for anything. I run a Corei7-920 with 12GB of ram (so its not like I would be waiting much anyway), but I feed the machine a lot of big jobs (kernel compiles using -j16, I have a script that builds a website --it calls other scripts-- that builds mysql from source, apache from source, php --with security patches-- from source, content management system from source, plus 50 support applications from source plus doing all of the installation from the scripts (configuration files modified from the scripts primarily with sed) plus all permission setting, etc.)) That script sucks the whole computer down for 20 minutes. ...and everything works as expected, including the drivers for odbc and odbc/openoffice, plus phpmyadmin. This patch seems to be working as advertised. Nummy!
In my experience the biggest time sink in Gentoo hasn't been compiling things (which, as you say, can be done while asleep or otherwise away from the computer), it has been trying to get the system back into a working state when your system upgrade fails halfway through with build errors leaving you in a halfway state in which you can't get half your stuff working... I eventually just stopped upgrading those two systems entirely. In fact, last week I reconfigured one of those machines using Arch instead, in part so I would be able to update things reliably.
Don't get me wrong, I like Gentoo, but I don't think I'll ever use it again for anything but something to tinker with when I'm bored.
Setting your vm.swappiness levels down from the default 60 to 10 seems to help the desktop issues this patch fix is for, too. Can't wait for the Slackware kernel packages to come out ;~)
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.
Honestly, I'm not sure. Certainly it's possible that the X server assumes /dev/tty7 (or whatever) as its controlling TTY - but I don't know if that's actually what happens.
And either way - a processor-intensive job launched directly from the GUI is going to have the same process group as other jobs launched directly from the GUI, unless some piece of code takes action to change the jobs' controlling TTYs.
The whole benefit in this test case presented in the video is derived from the fact that the processor-intensive job (the "make -j64" command) is run in a different process group (the xterm's TTY) from the GUI applications.
Bow-ties are cool.
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.
This is typical for a "computer scientist". Bad decision from a "using hardware effectively", sure. But if I'm waiting for the computer because the kernel is being efficient, it doesn't matter much, does it? I'd rather penalize system efficiency to see gains in my own. That's why we're not using a Babbage machine.
Basically you get really good interactive performance in exchange for massively losses in over all throughput and efficiency.
My efficiency, or the computer's? If I say "switch windows now" and I have to wait a quarter second, there's a problem with the software: the hardware is capable of doing so, and so am I. I should not have to upgrade my hardware to get a poor implementation to perform quicker; I should simply be able to have the implementation made better - particularly for something as low-level as kernel scheduling.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
Many terminal emulators include the option of creating or not creating a TTY to attach to when you run them.
Start a terminal and type w. You might find a pts terminal for each terminal you are running.
Probably you would. Some software doesn't work right if it doesn't have a controlling TTY - and some software specifically talks to its controlling TTY as opposed to stdin/stdout in order to bypass pipeline redirection mechanisms.
(For instance: terminal applications might check for a controlling TTY before using control codes. "ls" formats its output if stdout is the TTY. "ssh" prints its password prompt (and receives its password input) from the TTY)
A controlling TTY is also required for job control: CTRL-C to kill a process, CTRL-Z to suspend a process, etc. don't work if there's no TTY.
Bow-ties are cool.
But 400 lines of code in the subject line would make it 2x faster! LOC is the #1 metric for programming.
As a(n) UBUNTU USER I want to VIDEO PLAY MORE BETTER because CARTOONS IS SERIOUS BUSINESS
Bow-ties are cool.
I won't believe it until someone tattoos the source code on their body, or puts it on a t-shirt!
> Fuck support contracts. Real men fire up gdb when they see a koops.
Really? If I saw a koops, I'd probably call Mario & Luigi.
Makes me think of an extension to the Ubuntu tagline: "Linux for human beings".
"Linux for human beings, by human beings."
Well, ego plus it has a really dumb name.
Oh, wait...
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.
If I'm building a kernel with -j64, is desktop performance during that process really my top priority? And how does this scheduler change affect the performance of that build?
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.
I don't think that's something one should take for granted. We all make mistakes. And I think it was mentioned in the mailing list that this was an implementation of an idea Linus came up with in the first place... If so, it's natural he'd stand behind it.
At this point I'm feeling a bit skeptical. This one particular test case works because the build process winds up on a different controlling TTY. But what if the compile had been started, say, from within Emacs (launched from the window manager)? If Emacs has a controlling TTY in that case, it's the same controlling TTY (and thus, same process group) as Firefox and glxgears. Compiles kicked off from within Emacs don't get a separate TTY. Or, as someone else mentioned, what if another processor-intensive job (like a video encode, a Blender render, etc.) were kicked off from a GUI app not launched from an xterm? This patch wouldn't do anything for you in that case.
Alternately, what if the other applications had also been launched from the terminal window? They'd all wind up in the same process group, unless they detached themselves from the TTY.
This patch does wonders for preventing big jobs from messing up UI responsiveness if that big job is on a separate process group. But it seems like there's all kinds of common cases where that wouldn't wind up being the case.
It seems to me that Linus is latching on to this idea because it suits the way he works: which is fine - but that doesn't mean that it's going to be an important and useful solution for the rest of us. This is why it's important to consider whether the test case is really typical of what other people are doing with the system. If you don't do that, then it skews your whole perspective of how useful this patch really is. Linus is taking the attitude that this patch has been shown to work well, and therefore discussing the merits of the approach is meaningless. I disagree. Looking at this thing it seems like they looked at one atypical use case and, based on that, declared that the patch works miracles.
I think grouping processes by controlling TTY isn't a really sensible strategy in an age when a lot of our software doesn't even have any use for a TTY... I agree in principle with the idea that we should measure the merits of a scheduler strategy in terms of results, not academic merit... But the test cases have to be representative of typical use cases, and they have to cover all the common ones, or else they're meaningless. I really think Linus has missed that here.
Bow-ties are cool.
You'd think so, but:
"Initially a Phoronix reader tipped us off this morning of this latest patch. "Please check this out, my desktop will never be the same again, it makes a *lot* of difference for desktop usage (all things smooth, scrolling etc.)...It feels as good as Con Kolivas's patches.""
Emphasis mine. Fuck Linus. All he cares is how well it works in 1024-core machines. It's a miracle if anything that's useful at desktop actually gets approved, so I suspect this patch will have some flaw found to stop such abomination from happening. And a flaw, of course, means that it won't scale to 4096-core machines, or helps desktop machines. Either will do.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
So all those years you were lying? Lying that Linux was better than Windows even for desktop?
Actually Linus' said he wasn't expecting much and was quite surprised. This isn't some theoretical improvement. People in the real world are reporting excellent results left and right. Empirical evidence isn't influenced by bias.
I don't think this would change a thing - other than maybe making emacs itself less responsive - but if you're an emacs user you can't really expect much. Everyone knows vim is the right tool for kernel development ;-)
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
This is typical for a "computer scientist".
You are conflating several issues. They made a conscious decision to favor server throughput and to allow for scalability. Like it or not, desktop use is a minority use case for Linux. As such, it makes absolute sense to favor your target audience. Realistically, making the "right" decision is almost always the right decision. The real problem isn't that they desired high throughput in the CFS scheduler. The problem is, they decided to give throughput consideration to obscure server workloads over and above those of typical desktop workloads. Again, not hard to figure out why.
The problem with BFS is that is really scales okay to about four CPUs but has a lot of inefficiency to show for it. Things start falling off pretty quickly afterwards. By the time you hit 16 cores, you've reached all but a wall. At least, that was the result from the last benchmarks I've seen.
If I say "switch windows now" and I have to wait a quarter second, there's a problem with the software
But that doesn't necessarily mean someone made a poor choice. That simply means someone made a choice which favors different priorities. Besides, we already know the existing Linux scheduler can be improved. This story is one such example.
Lastly, at the end of the day, don't forget that scheduling is an extremely complex subject in which objective merits must always been considered; usually to the detriment of another consideration. The difficulty is finding a balance which covers the entire spectrum of user experience. To wit, we all know CFS does not currently provide.
This has nothing to do with open vs closed. This happens all the time in the corporate world. It has to do with simply being human.
Actually Linus' said he wasn't expecting much and was quite surprised. This isn't some theoretical improvement. People in the real world are reporting excellent results left and right. Empirical evidence isn't influenced by bias.
Empirical evidence can be influenced by bias. For instance, the bias that goes into selecting your test cases... The empirical evidence cited on the mailing list was all based on this same single kind of test - a big job running on a TTY. One flawed test case with good results, plus a lot of anecdotal evidence from people I don't know does not convince me.
I've been reading the mailing list messages a bit more and one bit I'd missed previously is that this is that this is the starting point, and other heuristics will become a part of auto-grouping later on. So from that perspective the situation seems rather more promising.
I don't think this would change a thing - other than maybe making emacs itself less responsive
But don't you see? In this case:
Emacs: launched from window manager, therefore inherits window manager's process group.
Big-ass compile job: launched from Emacs without a controlling TTY, therefore inherits window manager's process group.
Firefox: launched from window manager, therefore inherits window manager's process group.
Video player: launched from window manager etc. etc.
The result in this case is that the big compile job isn't conveniently landed into a separate process group. Not only does the user (for reasons that won't be apparent to someone who doesn't know how the scheduler works) not get the performance benefit, but in fact the performance of their desktop applications will be degraded as a result of being stuffed into the same group as the compile job.
Blah blah blah let's bash Emacs. Whatever. Still this TTY-based grouping does nothing for processes that don't rely on TTYs for anything at all... And it could put undue prioritization on tasks just because they happen to have a unique controlling TTY.
Bow-ties are cool.
14 years ago on the Amiga we had Executive which allowed the user to choose dynamically between six different scheduling algorithms.
http://www.amigareport.com/ar414/news6.html
If this was easy to dynamically change task schedulers then why is it hard now? Why is this hard coded in the kernel? Why is this not another module?
14 years ago on the Amiga I could dynamically change between six different scheduling algorithms using Executive.
http://www.amigareport.com/ar414/news6.html
Why is scheduling hard coded in the kernel? This should be configurable in user space maybe as a module?
The article points to the thread on the linux kernel mailing list, which is where much of the review of core kernel changes happens. Anyone can see the patches flying by, and you can always see the current (and historical) state of the main linux kernel repository by using git and pointing it to "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git". You can even see it using a web browser by going to "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree".
Does that include comments?
Is there a pluggable scheduler system yet? Can we poke some value foo into a /proc/scheduler/bar and select one on the fly?
I haven't used Linux in ages because on my desktop, it just wasn't responsive at the right times.
Cause you can patch BFS in anyway? :)
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 weren't used and this one is used. I'm not about to debate it here, as it has been beaten to death already, and with logic like "fuck Linus" you clearly have me outclassed in any such debate.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Maybe I am missing something. The terminal used for the build is launched from the Window Manager. What is the difference?
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Maybe I am missing something. The terminal used for the build is launched from the Window Manager. What is the difference?
The difference is that the terminal creates a TTY session (interactive command shells almost always have a TTY, as it's required for job control and window resize notifications and other things), and therefore (under the auto-grouping process scheduler) a separate process group. The build started in the terminal window could spawn a thousand processes, and they'd all wind up in that same process group.
The concept of process groups is rather new to me (it's kind of a new thing, right?) and so my understanding on some of these points may be incorrect: but my understanding is that this scheduler helps if and only if that big compilation job winds up in its own process group. The kernel periodically context-switches away from the whole process group to do other things. That's where the benefit comes from: if a 64-process build were running at the same time as a video player (maybe itself 2 or 3 processes), that video player would probably get less than 1/30 of the total CPU resources. The fact that the compilation is using more processes effectively gives it more priority. But if those 64 processes were part of a single group, and the scheduler is servicing groups with more or less even priority, then that video player (assuming there's just the two groups, and nothing else is in the video player's group) gets to claim about half the total CPU resources...
Creating a terminal window creates a new process group - and the process groups are what causes things to behave differently under this patch.
Bow-ties are cool.
Or, you know, maybe he gets so many patches that every once in a while, even a good one can slip through the cracks. I mean, you try dealing with the literally hundreds of people emailing their really "great" ideas to you every day for inclusion in a kernel that you not only rely on personally, but put your name and stake your reputation on. Now, I'm not going to claim that Con was some idiot, but most of the whining about his patch not being accepted that I've ever heard was from people who probably couldn't even tell the difference between C and C++. Or if they could, they were too busy bitching to write their own patch for inclusion in the kernel. As for Con? I have a lot of respect for him, because unlike the whiners, he sucked it up and started all over again. Linus isn't perfect; he's not a god, but he knows a damn sight more than anyone here bitching about him rejecting patches.
Nathan's blog
Maybe he did realize he was wrong; then there's always the consideration to be made that Ingo has been around for ever in the Linux kernel community, and Linus trusts him. Not to cast aspersions on Con, but if someone came to you with some "great idea" and just give it to you, would you take it? Especially for something as important as the scheduler, where use cases you can't even imagine are the norm. Use cases you can't imagine unless you've been developing one of the most widely used kernels, in applications from micro-embedded computers all the way to highly distributed clusters, for going on almost twenty years. The three years Con spent on the scheduler may sound like a lot, but it's nothing compared to the man-years that have been put in by the Linux kernel developers; and, yes, Linus has his favorites, because they have come through time and time again, and have been around forever.
Nobody's perfect. And it's obvious you haven't spent much time on LKML; people regularly flame and get flamed; it's part of the culture, and it's also a way to winnow out those who aren't willing to stick with it.
Nathan's blog
Perhaps; but what of the possibility of scheduling groups of processes, where "group" is defined differently? If nothing else, this patch could lead the way to being able to schedule "process groups" where the partitioning into groups is done differently (eg, background services vs user apps, foreground window vs background window, etc).
Nathan's blog
Maybe you are right. I certainly concede that I haven't looked at the code, or analyzed things much at this point. Give it a try and let me know (I don't do emacs.)
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
As I posted above, normally when Linus flamed someone he was both entertaining and right. In this case he was neither.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Why would you need a directory with few thousands of files on the desktop computer?! Well ok, under linux there is /usr/bin (and I don't like this design), but under windows?! And what do you do after you opened this folder?
So what you are saying, this would be a fantastic scheduler for the people (like Mom) who would have to adopt Linux for it to ever succeed on the desktop, but since it doesn't play well with the enthusiast it's ridiculed and thrown aside.
Why do people wonder why Linux has never caught on with The Masses?
Yeah, that's true with this particular implementation. But I think the concept can be extended. Since the essence of the patch is that it automatically creates process groups based on a criteria (in this case the TTY number), I think it could work something like this: the desktop environment runs a daemon in the background that manages at least two process groups--a background process group and an everything else group. Things like dvd rippers, media encoders, matlab simulations, whatever go in the background process group, and the kernel handles the rest.
The question for scheduling always is "what needs the highest priority?" This patch groups process by tty because its a natural way of separating processes. Obviously the ones that should have the least latency are the ones you are actively using (ie: in the active tty). To do this with a modern gui, the desktop environment has to get involved somehow with the process grouping. Because otherwise there is no way for the kernel to know which processes are being actively used and which ones are in the background (it knows which ones are using the most cpu, but that's about it). Even for the desktop environment it will be tricky, but it has a lot more information to work with than the kernel alone--which windows are on which workspace, which workspace is visible, which windows are on top, which are minimized, when was the last time an Xinput event was in a window, is the application in the window constantly updating the framebuffer, etc....
Yes that is what happens when memory is full and then swap is also completely full, it kills things off until there is enough memory that something can run instead of it being completely locked up. I don't think it's at random though.
I've seen it on a few times cluster where users try to squeeze 50GB of data at a time into 8GB memory plus 2GB swap instead of getting the software to handle things in smaller chunks. It seems to kill off the monitoring software early (ganglia) and the main user process that is consuming all of the memory late. When you have a point where the user process can just keep running in memory plus swap with just about everything else killed off it will do so. At that point it's going at glacial speed and won't let you log on (no spare memory), so it's a case of telling the user and getting them to change their settings, rebooting and starting their job from scratch. If something is going to consume all memory plus swap it usually doesn't get very far before it bogs down. Often the new job gets further in a couple of minutes than the stuck job did in a couple of hours.
I've never used Gentoo personally, but I feel that I don't have much of a reason. For learning and tinkering there is LFS, which to a greater extent is impractical for real work. That's where Arch comes in. It's customisable enough to do anything that I want while still having a great package manager. For a more typical instalation I use Fedora.
Basically, Gentoo seems to occupy that end of the spectrum between LFS and Arch that I don't seem to need or want. However, I'm still tempted to try it at least once.
There are 10 commandments: 01)Thou shalt love the Lord Thy God 10)Thou shalt love thy neighbour as thyself.Matt22:34-40
Please point out where Linus flamed Con..
Also Linus was right in the end..
http://kerneltrap.org/node/14023
It's been fairly well documented but you still seem to ignore the reality of what happened.
http://kerneltrap.org/node/14008
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
I've done a quick scan and the autogroups thing creates a new scheduling group whenever a user process sets or clears the current CTTY value for the process. This should give a process grouping almost identical to the session id (setsid(3)). You can see your current session ids with ps(1) in the SID column.
I can't tell for sure without trying it but I think this will give a new process group for each application started from many GUI menu programs too because they actively detach you from the CTTY. Even if it doesn't there are many user programs that change the CTTY, the simplest is probably script(1).
But, this is definitely one of those changes that demands the question of why it wasn't though of before; why didn't I think of it, I know what session IDs are and I know about process scheduling groups. It's obvious, in hindsight, that they are a pretty good match for each other.
You make it sound like its the only game in town. Its not. For your typical Mom, CFS works fairly well too. Generally speaking, most people are not multi-taskers. As such, CFS work great for them too.
Besides, its widely believed that Linux desktops have been terribly under represented. Some estimates actually place it on par with Apple desktops. Aside from that, its server presence is massive. Linux has clearly caught on with the masses. The hair splitting allowed is where the actual desktop numbers lay. Are they closer to the general estimates everyone knows are wrong and too low or are they actually on par with Apple?
And none of that reflects reality. There is also a lot of surround threads which properly light the scene. My depiction is spot on accurate.
He choose CFS over SD because SD behaviour was inconstant among users' computers
That's why people claim bullshit because CFS was even worse. He was hypocritical. Everyone knows this.
Con would argue with people sending him problems rather then accept them as problems with his code
Yes and no. That's not entirely true. Con would "argue" with people to explain what it was they saw. Scheduling is very complex. When people saw a result which differed from their expectations, they cried error. Some were legitimate. Most were not. Some were biased for server genre. The "legitimate" complaints were always addressed AFAIK.
Linus didn't want code in the kernel that would only work well for certain users
And yet he choose the option which created the largest deviation - which was his own option - CFS. Hypocritical to say the least.
Linus didn't want code maintained by someone that was so hostile to others' critique
This is the gruff skill set to which I spoke. But people ignore that he was full of bullshit. Con has YEARS of proof to show that Linus was completely full of shit in this regard.
Linus states that he believes the desktop is an important platform
Of course it is - until it demands a compromise to the detriment of server performance - which he's endlessly on record more or less saying.
So basically, your representation does not accurately reflect the situation in the least and shows no ability to read between the lines or any knowledge of context outside of the thread in question.
In 1980, The IBM mainframe operating systems included "Performance Groups". Workloads were classified into Low CPU interactive and High CPU background and also some must complete performance group(s). It like being born again to see it coming to Linux as a new patch. Now I would love to see a "VM CMS" environment under the linux kernel
Leslie Satenstein Montreal Quebec Canada
That article is about Wine gaming specific benchmarks, where as a wider range of benchmarks showed SD was superior. Cherry picking one benchmark doesn't prove that Linus was right.
For one, Linus argued that one use case shouldn't be focused on, but rather the wide range of uses for the kernel. So why cherry pick one use-case?
Secondly, Linus argued for three years that Linux didn't need a new scheduler at all, and that Con's approach was completely wrong.
Even Ingo admitted his CFS was based on SD's principle and was largely inspired by it. The fact that CFS performed vastly better than the previous scheduler actually proved Con was right and that Linus was wrong in arguing for no new scheduler.
http://kerneltrap.org/flames
Linus justifies the decision not to go with SD saying Con was argumentative and wouldn't support his patches. Con had been supporting and improving them for three years. I emailed him personally and got support. He answered questions on the LKML and on his own mailing list. He listened to criticism and constantly improved his patches for years.
Linus not only made his decision on personality rather than code, he did so by making up lies about Con as a person.
Face it. It was a dick move. And up to that point, I was a big Linus fan.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Perhaps; but what of the possibility of scheduling groups of processes, where "group" is defined differently? If nothing else, this patch could lead the way to being able to schedule "process groups" where the partitioning into groups is done differently (eg, background services vs user apps, foreground window vs background window, etc).
Yeah, one of the things I missed in my first appraisal of this patch is that it's a starting point, and that they're planning to add more heuristics to the implementation of "auto process grouping" in the future.
An implementation of auto process groups based only on controlling TTY seems very limited given how much people do these days without a TTY device attached... But if you take that as just one of a set of heuristics - suddenly it makes a lot more sense...
Though I still have some concerns about the idea. It assumes a particular model of TTY usage. If a distinct controlling TTY always means a new process group, that could cause problems if a piece of software makes more extensive use of PTY devices.
Bow-ties are cool.
Windows Vista and 7 both run fine on older hardware
How old is older? ASUS sold the Eee PC 900 in the fourth quarter of 2008. Its Celeron 900 CPU was comparable to the PIII-866 in new desktop PCs made in the fourth quarter of 2000, and it came with 512 MB of RAM. Even when one replaces the slow 4 GB SSD with a faster and larger SSD, we're talking about a 2-year-old PC that does not meet the published system requirements of Windows 7.
Link some evidence or GP has you beat.
Is there another metric that can be used to determine which group a process should be bound to? Perhaps the group (from /etc/group) the process is running as. Or, y'know, just change the menu launcher to specify the group at execution time. Like how 'nice' works. Or an env var on the command line. Doesn't have to be automagic.
Perhaps the group (from /etc/group) the process is running as.
As most machines are used as single user, all interesting processes belong to the same user, and also the same group...
Next idea?
With a treatment like that, it's a miracle he didn't call it the 'Up Yours' scheduler.
Religion is what happens when nature strikes and groupthink goes wrong.
My depiction is spot on accurate.
Arrogant, much?
Everyone knows this.
No, not everyone does.
Kindly take your generalizations and fuck off.
Thank you.
How about: "Or, y'know, just change the menu launcher to specify the group at execution time. Like how 'nice' works. Or an env var on the command line." Also, ever heard of the setgid bit? Plenty things run as the current user but with a group specific to the app or nature of it's task
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)
I love linux
This doesn't just happen to programmers. After a few years working for federal government I have seen people's egos lead to poor public policy, wasting tax payer dollars. The question on the table is less "What is the best way to spend this money to provide a public benefit" and more about "who suggested what solutions and how right and / or wrong that person is".
I'm sure this also happens in the private sector, ie Discovery channel lawyers suing a fan site that gets money from the advertisement department of the same damn company. Probably some lawyer just wants to win the suit for his own ego even though it's ultimately bad for the company.
The reason Lennart on LKML and many other people objected was that it was (and still is, look at the config option description) described as a generic optimization for the desktop use case. That is patently false, this only helps people whoe run "make -j64"...
Improving responsiveness for developers is awesome. Trying to sell this as something the makes the linux desktop more responsive in general is dishonest.
Or, y'know, just change the menu launcher to specify the group at execution time.
Why, among the zillions of settable process parameters would you pick the user group for that? There are many other process parameters that would be more appropriate and that wouldn't have access right side effects.
Like how 'nice' works.
Nice doesn't use group ids
Or an env var on the command line.
Slightly better already. But with the environment, you would have the drawback of the kernel having to parse the environment.
Also, ever heard of the setgid bit?
Sure. But it sure would be a nightmare to administer all those setgid launch scripts, and making sure none would introduce a subtle security hole.
Plenty things run as the current user but with a group specific to the app or nature of it's task
Sure. So those apps depending on a specific group will stop working because the window manager set a different group than the app expects for scheduling purposes?
But in any case, all this has become moot now
When new-fangled speeds like that became available, a baud was no longer == 1 bit per tone per second, and I objected to the sloppy language. I remember - uphill both ways...
why would the window manager change the group instead of init/linux knowing to put that existing group+process name combination at a certain priority? But you're right. Why among the zillions of settable process parameters would we pick something limiting and not realistically indicative of the requirements of the task (such as being launched in a tty or not!) This was more or less my point to begin with. Just meaning there are other ways to do this that are probably both more manageable and more effective.
I have no problem with people spending their time doing whatever they enjoy, but I'm far more impessed with the guy who happens to own a Logitech MX1100 mouse but wanted to use all its extra buttons on Linux, and figured out how to make that happen: With the patience to navigate the bureaucracy to submit it; while observing best-practices, and working with other projects; and with the selflessness to also make it easy (both to use and extend to similar models).
That guy's unsung efforts will benefit other Linux users much more, and have a much greater chance of being full-time part of Linux, than trying to replace a stable kernel system (which has to satisfy countless varied environments), just so that your desktop task-switching / background-task performance can be negligibly improved.
That's my take anyway; I'd sure like to see more kudos given to the people who make more tangible contributions, but I realize there is an aesthetic quality / placebo effect that comes with these sorts of changes that lots of people appreciate.
// MD_Update(&m,buf,j);
Linus justifies the decision not to go with SD saying Con was argumentative and wouldn't support his patches. Con had been supporting and improving them for three years. I emailed him personally and got support. He answered questions on the LKML and on his own mailing list. He listened to criticism and constantly improved his patches for years.
Linus not only made his decision on personality rather than code, he did so by making up lies about Con as a person.
Face it. It was a dick move. And up to that point, I was a big Linus fan.
Made up lies? I read the LKML archives and saw for myself the incidents where Con was argumentative with people reporting problems. Linus isn't going to care about a billion anecdotes about Con or any other developer being super great in other forums, he's going to go with what he sees in the places he frequents.
You're choosing to believe only one side of the story because you got a warm fuzzy from talking to the guy. To many others, not just Torvalds, Kolivas comes across as a drama queen who reacts badly to criticism. The end to the whole affair was Kolivas pulling a classic "look-at-me" move with all the "I QUIT" drama.