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 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/
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.
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).
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.
I think this is some sort of heresy against the great gods of geekdom. Users should want what we want them to want, clearly they can't be trusted to figure out their own wants.
Seriously though? It's a good idea, but only a few companies in the Linux business have the resources to do it on any kind of scale. Most of those are the companies that would benefit least from the tests in the short term, because they release on such a conservative schedule that it might be years before they run a kernel with the improvements suggested. There's advantages and disadvantages to any model and one of the disadvantages of the very distributed way "Linux" is developed is that it's hard to get changes and improvements to whole OS. Note that I put Linux in quotes up there. What I mean is not per se the kernel, or more pointedly not only the kernel, but the whole OS.
Let's say Red Hat does some usability tests of the type that Apple and Microsoft do a lot of. Let's say that they find several areas that users think need improvement in their workstation OS. If they were Microsoft, they'd divide the improvements up into sub systems (kernel, UI, user tools, IE, whatever) and send them to the appropriate team for feasibility studies and such. Microsoft can force the teams to at least give a good reason why they can't use a suggestion, even if they can't always force the suggestion to be implemented.
We aren't talking about Microsoft though. We're talking about Red Hat. So they divide up the improvements into subsystems and figures out that they personally control like three items on the list (mostly administrative tools). The rest they send out to other projects (Linus' Kernel team, the X.org guys, Mozilla, Oracle (for OO.Org), the FSF, etc). Any one of those teams, might use the suggestions, politely thank Red Hat and ignore the suggestions, make rude gestures and wander vaguely away... whatever.
Even assuming that the relevant group takes the suggestion seriously, Red Hat typically releases on a very slow schedule; and they try very hard not to increment subsystems any more than they have to for security reasons within a given release. So if they give Linus' team a kernel suggestion, it might take the kernel team a year to implement the suggestion. Then it might take Red hat another two years to actually start using a version of the kernel which has the improvement. Between their own conservative release schedule and the fact that they have little control over what gets done with their own results, you have to wonder if there's any financial incentive to doing usability studies.
Of course the arguable advantage of the model is that if you really want an improvement you can design and implement it yourself. Or take something like this patch and apply it to your current kernel. Which is great for those of us who can do that. A little less great for Joe Average user.
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
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
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.
Of course the arguable advantage of the model is that if you really want an improvement you can design and implement it yourself.
Indeed. Anyone can do it. And when "anyone" includes the likes of IBM and Oracle and HP, I just fail to see why they never have. Maybe I am wildly mistaken, but it seems that millions of users want nothing really hard, just easy, fast and free access to a few games, a better-than-microsoft IM client, mp3 downloads, etc. Why can't a user experience ease of use in these simple things, is beyond me. Even joe-user-targeted, desktop-focused Ubuntu doesn't come with an easy button for an IM that a teenager who's addicted to msn can quickly get comfy with, and any games better than solitaire. Next step - call me and ask to install "the real" msn messenger. Heck, the kid should have gotten something that kept him entertained talking to his friends for at least *one hour* until he figured out he wasn't running windows.
Build your own energy sources from scratch. http://otherpower.com/
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?
1. don't buy that one
2. I have both on my phone
3. HTC G2. You can buy it outright and do prepay or month to month with t-mobile.
Before you complain do some basic research.
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.
2.6.38 will be teh year of teh linux desktop!
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.
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/
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.
Slackware users build their own kernels, so we can put it in any time we like.
...laura
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.
How do we reach a 10% figure?
Build your own energy sources from scratch. http://otherpower.com/
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.
Canonical.
--srj/mmv
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.
Indeed, I find that Linux has an almost miraculous ability to convert users into developers. I've encouraged several friends over the years to use it, and out of those that have actually done it, most have not just stuck with it but have even surpassed me in some ways. It can take a teenager or young adult who knows barely anything about coding or even much about computers and can turn them into a coder or admin in no time. My theory is that people follow a sort of a path:
1. They use a bloated (but more immediately user-friendly) distribution like Ubuntu.
2. They hear about other users with lighter software and try it out. It requires a bit more configuration to be the way they want it to be. In the process, they learn more about their system and they learn many useful things.
3. The drive for improved performance and usability leads them to learning more and more and doing deeper and deeper configuration until they know a great deal and are very comfortable with their system.
4. The "scratch that itch" (ESR) effect comes into play; they see deficiencies in existing software and go out to make their own.
5. Before long, they are contributing to several projects, have a technical blog, and are advanced users.
It seems to be some sort of natural progression and it's interesting to see it happen over the period of several years. More significantly, Linux seems to turn a higher percentage of basic users (even those of the luser variety) into developers and advanced users. This seems to be why Linux progresses at such a fast pace; its users actively encourage other users to involve themselves on a deeper level.
Yet Another Tech Blog
(but so much more, including game and movie reviews)
http://yanteb.peasantoid.org
Hand-carved from meteorites.
http://lkml.org/lkml/2010/11/16/330 - user space solution that does the same.
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.
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.
Yes, exactly. I want to make a point without causing a big row. I don't claim a moral high ground, which is why I made sure to say that I don't doubt his sincerity. WTF would be moral high ground with anecdotes about operating systems, anyway?
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!
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.
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.
Apparently your friends are far more intellectually curious than any of mine are.
I have found there are just two ways to go.
It all comes down to livin' fast or dyin' slow. -REK, Jr.
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.
Obligatory xkcd reference "Cautionary": http://xkcd.com/456/
vi +
I won't believe it until someone tattoos the source code on their body, or puts it on a t-shirt!
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?
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Makes me think of an extension to the Ubuntu tagline: "Linux for human beings".
"Linux for human beings, by human beings."
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.
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.
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.
Community firmwares now include the Google apps in a separate unrelated package, which gets flashed after the firmware stage.
A year ago, the procedure used to be to back up the Google apps from your phone, install CyanogenMod, and restore them. Is this still the case, or is there a newer yet still legit way to get these apps? A bit of browsing CyanogenMod's wiki referred me to Google for Android, which appears to have everything but the Market.
Every Android phone has had digitally signed firmware, including the very first G1.
But apparently, some newer phones block the use of a custom recovery that allows verification to a root certificate other than the phone maker's.
N1 was signed but semi-enforced (only for DRM-opting Market apps, which was bypassed).
About what fraction of Market apps are DRM-opting, and are any major ones?
HTC G2.
Google Product Search for unlocked htc g2 confuses me. There appear to be two "HTC G2" models: a $300 model (called "Magic") and a $600 model (apparently the "Hero"). Which did you mean?
You can buy it outright
For one thing, if I don't need a telephone, just about every Android phone bought outright costs far more than the base model iPod touch 4. Why is this? And even if I do buy a phone and just never use it as a phone, if I end up finding the HTC G2 unusably unergonomic, how can I return it without paying a $100 restocking fee?
t-mobile
Where available.
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".
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? :)
Ubuntu doesn't come with an easy button for an IM that a teenager who's addicted to msn can quickly get comfy with
I've always thought pidgin was quite a nice program
especially now that it integrates with Facebook, and GTalk, which between them have pretty much killed off MSN/AOL(thank god)/ICQ/IRC in my lil' circle of friends and family...
I'm not sure that Linux did the converting. More likely, people with that level of curiosity will find things to tinker with and end up as power users in whatever subject they were tinkering with. And people with that "can do" attitude are probably more likely to want to try an "alternative" desktop OS.
I grew up with windows, and between dos, the registry, and basic scripting to trying foxpro / vb / etc.. it was just as nice a learning ground as linux, especially if it was your first computer experience. Most things worked well in windows, so you spent your time trying to do things you wanted (creating a program, tweaking an opensource one, learning to automate tasks with scripts, etc..) , rather than just trying to make things work (as was common with very early Linux releases).
Perhaps you can say that because Linux often requires tweaking, or outright fixing of software that is temperamental, one is forced to learn things that they might not have wanted to, or bothered to before. And some percent of them end up enjoying fixing/creating and go on to careers in computers. But I don't think that there is anything inherent in Linux that makes someone more curious about computers than they would have been if they were using another system.
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
I have to say that I went rougly the other way: I started with Linux because I was highly discontent with the then-current Microsoft offerings, finding them unwieldy and unstable. I started way back on Slack 6, where the first step of the installation process was compiling your own kernel and gcc three times to get them pure :-)
Later I switched to RedHat (3 or 4, I think), and was also messing in some code - mostly for my own benefit, can't recall ever committing anything because I didn't think the changes I made were useful for enough people to be included.
These days, I just run Ubuntu - I've been through the whole trial-and-error config file thing, it's given me a good understanding of many things, but now I just want something that simply works so I can get on with other stuff.
These days, the MS offerings (well, some of them) are at least a lot more stable, although I personally still find them unwieldy - I guess I'm no longer used to having my OS babysit me. I even occasionally recommend that a friend who needs a reinstall sticks with windows, depending on his needs, although I always offer them Linux, too. I flat out refuse to support windows boxen, though :)
What a depressingly stupid machine.
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.
I generally come from the perspective that your computer is as stable and user-friendly as you want to make it. Unless you're running hardware with poor support (Broadcom, anyone?) you're not going to have a really rocky experience with Linux. I like running computers with little resources and making my machine rock-solid stable and perfectly configured to my tastes. This is a process that takes dozens of hours of messing around and experimentation, but it pays off in the end, in my opinion.
Yet Another Tech Blog
(but so much more, including game and movie reviews)
http://yanteb.peasantoid.org
I was making more of a point that Linux (the software) enables such tinkering and Linux (the community) encourages it. A truly motivated person would do it anyway, but such people are few and far between. A good community spirit draws in and encourages people that otherwise would do nothing.
Yet Another Tech Blog
(but so much more, including game and movie reviews)
http://yanteb.peasantoid.org
It's all about recognizing who would be receptive to it. I've talked to almost all my friends about it (and all of them definitely know I use Linux) but most are uninterested or are too ignorant to start using Linux right away -- they would be lost almost immediately. Instead, I heavily encourage Linux to those people who are generally hobbyist types, are intelligent, and have time on their hands.
Yet Another Tech Blog
(but so much more, including game and movie reviews)
http://yanteb.peasantoid.org
This is the great battle with distributions like Ubuntu. There's a fine line between auto-configuring and helping the user make decisions (or making decisions for the user) and preventing the user from making decisions on their own.
Yet Another Tech Blog
(but so much more, including game and movie reviews)
http://yanteb.peasantoid.org
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.
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.
It was a combination of Windows 95 being comparatively idiot-friendly along with an absolutely massive influx of idiots when public access to the Internet started to take off, and the web began to come into its own.
Those two things happening at about the same time changed the world in a lot of ways. For example, the terms "top posting" and "bottom posting" came into existence right around this time, as millions of new users exposed to email for the first time got their hands on Outlook Express, with its completely broken editor that made formatting a message correctly almost physically impossible.
When I really think about it, the biggest difference between being an old-school DOS hacker and being a modern Linux hacker was that in the DOS days we had BBSes, and those of us with net access had Gopher and Archie. I got out of development around 1995 not simply because everyone demanded GUI applications, and early Windows development sucked, but also because when I first got on the web, I found a good many alternatives to every application I had ever developed. You think KDE vs. GNOME is a big waste of resources? One of the DOS applications I actually made money on was a utility that has a close equivalent as part of the GNU toolchain, and I abandoned development when I realized there were about six alternatives that predated my own, and were further along.
We DOS hackers were working alone for the most part, or in small, isolated teams. The web changed all that, and then sites like SourceForge took it all to the next level. Now, collaboration is easy.
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.
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.
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
Use linux if you want to know why your computer works. Use mac if you don't want to know why your computer works. Use DOS if you want to know why your computer doesn't work, and use windows if you don't want to know why your computer doesn't work.
"People don't want to learn linux" hasn't been a valid excuse since '03.
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);
Look deeply in that line. What do you see? I see a hat. A red one. A fedora, I think.
I know tobacco is bad for you, so I smoke weed with crack.