Preemptible Kernel Patch Accepted
An Anonymous Coward writes: "The preemptible Linux kernel patch that was originally introduced by MontaVista Software and more recently championed by Robert Love has been merged by Linus Torvalds into the main linux development-kernel tree, beginning version v2.5.4-pre6. This adds a far greater degree of real-time responsiveness to the standard Linux kernel, by reducing
interrupt latencies while kernel functions are executing. The story at LinuxDevices.com includes comments by Robert Love, and there is also a recent interview with Robert Love about the preemptable kernel here and a whitepaper about the technology by MontaVista here."
Hey Beavis Linus now is preemptive
To summarize what you're saying...
[] Better porn viewing experience
Yeah. As a self-confessed "newbie" to the kernel, you'll find a lot of the time that Linux is catching up to 10-, 20- or 30- year old technology that other OS's take for granted. It's what you get for choosing "free" software, I suppose: software of such low quality and limited feature set that they couldn't sell it if they tried (viz the LNUX stock ticker).
This must be a bottle-neck in the GTK signal
routing code; I beleive it could be eliminated with
some manual optimization (i.e. loop unrolling, and
inline assembler.)
file it as a bug, and let the developers take a look
at it. I am using a GHz machine, so I don't notice
the 2D math calculations. Or maybe, my monitor/gfx card
have higher refresh rates.
Wow. Another "logged in" user thinks he has something to say. Just remember this, login boy: registering a Slashdot username is exactly the same as licking CmdrTaco's ass. That's a hygiene risk I'm not prepared to take - why were you so eager, shitlicker?
despite appearing mature and clueful, way off mark.
No, despite trying to sound like the wiser one, you are way off the mark. If this was just a patch that unplugged a logjam it would have been applied a very long time ago. No, it took time because there were tradeoffs. Yes, those tradeoffs may not be entirely tangible or even noticeable by the end user, however there *are* tradeoffs.
For more proof, I'll direct you to the large number of clueful responses to my original question.
*Condense fact from the vapor of nuance*
Habing the kernel be preemptable.. hay look p0rn... will greatly help with the responsivness... Where a good place to get an OpenBSD ISO... of most processes in Linux... XP has a Teletubby interface... thus increasing productivity. Not like those... wow! free cheese... Max 9.0 people who can only do on thing at a time.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
False. There *is* a tradeoff. And you probably want to take an Operating Systems course before spewing "there is no tradeoff with Free Software" nonsense. (BTW, I wanted to ask the same question).
Anyway, here is how it works: a ready, higher-priority process can kick off a running, lower priority process before the running process's time slice expires. This does indeed improve responsiveness so that your machine "feels" (*)faster, but in reality it actually runs slower. The cost of pre-emptible kernel is that it does more process switching than a non-preemptible one (see above, it can (and does) interrupt a process before its time slice is finished). More process switching requires more CPU time, concequently, less CPU time is spent on actually doing work. So yes, the good thing is that it decreases latency (hence better responsiveness). But the bad thing is that it decreases throughput (the amount of work actually done) because of the increased process switching overhead.
(*) The reason your machine "feels" faster is that the GUI becomes more responsive. But that is pure illusion! Your machine actually does less work. Thus, the pre-emptible kernel patch would probably be useful for workstations, but you definitely don't want to use it on a server.
So the question becomes: what is the throughput/latency tradeoff with the current implementation of the preemptible kernel?
___
If you think big enough, you'll never have to do it.
Oh come on sydb you coward give me a kiss :-)
*Condense fact from the vapor of nuance*
Oh, I also have Win2k Advanced Server running in VMWare, Rolling Stones playing on XMMS, and four *mozilla* browser windows (now that's a RAM hog). I detect no lag in my system at all and I sse this patch as something that'll be moot in one year.
Yes, it'll go the way of DoubleSpace. CPUs are cheaper by the day and so is RAM. Once people start to upgrade this'll be a moot patch. I do not see what the hoopla is since my system is definitely not state-of-the-art and yet it's responsive as all hell.
Anyhow, just my thoughts...