Slashdot Mirror
Linux Gets O(1) SMP Patch As Late Christmas Gift
bodin writes: "Now that new-year's parties are over things are getting boring again. For those who want to see and perhaps even try something more complex, Ingo Molnar is
announcing this patch that is a pretty radical rewrite of the Linux
scheduler. This is big stuff!"
of myself)
I don't know if in 2.ed kernels Linus still likes the "small patch" idea. but this is pretty amazing. I am no kernel coder, but some of these tests showed 600% percent improvement and (seemed to me to be) impressive scaling. All the kernel gurus out there, what is the chance that this will make it into the kernel? (2.5)
What comes first, finding a teacher or becoming a student?
There's a second factor in that - the cost of actually creating the processes/threads. On the whole threads are cheaper to create than processes IIRC.
Davide Libenzi's been shooting some holes in the architecture of this patch--he's also written a highly scalable multiqueue scheduler. He and Mingo are currently hammering out some ideas, almost certainly something will go into 2.5 but this may not be it.
rage, rage against the dying of the light
Why do we want everyone's grandmother to be using Linux? To do that, we'd basically need to design a system like MacOS (pre-X) -- very simple UI, lots of big-name applications (Office, Photoshop, etc), and good marketing. All 3 of these are completely unappealing to me, and are not the strengths of the open source community. Why not just design the best OS we can, the OS we want to use? For me, that means a functional GUI (Gnome or KDE more than suffice), but an absolutely rocking server OS + software development environment.
I'd much rather see Linux replace Solaris/AIX/HPUX/Win2k. As for desktop dominance, who cares?
I wish SPI would get a PayPal account so I could make these "warm fuzzy" donations on the spur of the moment.
Bob-
The Ludwig von Mises Institute. The reasoning individuals economics
Apache would be MUCH faster if the Apache developers would give up on the outdated and innefficient method of using a separate process per connection, and went with a non blocking I/O model like Boa, thttpd or Zeus. A non blocking I/O model is much better, from many standpoints. It places the I/O handling back in the kernel where it belongs, reduces memory usage and drastically increases speed.
I've talked to a lot of people about this issue, and spent a lot of time reading through the Apache developer mailing list. The main reasons that come up is that Apache is meant to be correct first, fast second, and that it is harder for people to extend Apache because it makes the code more complicated. The first reason is invalid, because it's quite possible to make a web server correct and fast at the same time. The three web servers I mentioned prove this. And there are several more non blocking web servers out there. The I/O is a very small part. Given a proper design, everything else can easily work with that model. Extending it is not made any more difficult, because one would very rarely, if ever, modify the base I/O model. You have normal HTTP and HTTPS, and that's it. Anyone who would be extending that critical portition of the web server should be able to understand the conceptually simple concept of non blocking I/O, especially as it is explained very well in a variety of sources.