Slashdot Mirror
Linux Kernel Performance How Will 2.6 Measure Up?
An anonymous reader writes "This story offers some interesting performance comparisons between the latest stable Linux kernels (2.4.x) and the latest development Linux kernels (2.5.x), comparing performance on both a single processor and dual processors. These numbers help validate that the upcoming 2.6 kernel will outperform the current 2.4 kernel, at least in some instances..."
Yes, It's faster for most tasks, especially interactive and high load tasks.
But how is this news? Ever since the thread on Kernel Notes a month or so ago, most of us have known it this.
Of course, the real solution would be to not need to compile software (plug plug :)
What is the weakest specced machine that anyone here is getting productive/useful work with Linux done on? Do people use Linux on 468s at 12mhz? P75s? Just curious.
but will it corrupt my filesystem?
Performance is important, certainly, but I think some people (*cough* overclockers *cough*) assign it a bit too much importance.
Tarsnap: Online backups for the truly paranoid
It looks like the new kernel better utilizes multiple CPUs. This is a great thing. Linux needs better support for SMP systems if it is going to play with the big kids in the high-end server market. (I know, Linux is partially there).
more resistant to the /. effect?
Really... I mean, that is the whole point to actually making an IMPROVED product, right... So it's an IMPROVEMENT over what was offered before?
I know, I know... Don't beat the messenger...
But, I swear, if a company uses that line to sell a linux distro, I'm going to beat their marketers.
Good selling point. Well, yeah, it does ok, I guess... In a few places...
krystal_blade
It will be easy to motivate our fellow man; there is hardly anything people treasure more than not being annihilated.
I wonder how well it compares to the BSD kernels, in both performance and stability?
P-75 w/32Mb RAM firewall
P-75 w/32Mb RAM printserver for 3 node network. Sure, small time lag when sending graphics to print server but overall pretty nice job.
People don't just use Linux on desktops, they also use it on handhelds, wearables, and embedded systems. So, a 486 running at 12MHz isn't out of the question at all.
When it comes down to it, you only get cost-effective scalability by using distributed systems or clustering. In fact, for really large systems, it's the only possible way at all.
Something like OpenMosix should really be a standard part of the Linux kernel already, as should other support for simplifying clustering, distributed computing, communications, and distributed shared memory. Distributed systems and clustering is the future, not SMP.
Amazing, I've been running FreeBSD since 2.8 and I've never had an unresponsive system even while doing a build world; I guess the 2.4 kernel is alot worse than imagined.
This is, by and large, the fault of the scheduler, largely unchanged in 10 years and described by Linus, even whilst he wrote it, as a 'hack'. However, it worked, and Linus, being the extremely sensible and conservative maintainer that he is, kept it until recently - process schedulers are difficult things to get right, and their performance is crucial to the performance of the kernel as a whole. Not to mention that for the tasks that Linux has been used for historically, primarily low-volume server tasks on low-end hardware, it isn't really a bottleneck.
Still, the scheduler has been gutted and rewritten for 2.6 by Ingo Molnar - the now somewhat-famous O(1) scheduler, which performs much more fairly under load, and dispenses with almost all of the strange pauses and scheduling glitches under load. Current vendor kernels based on 2.4 (Red Hat's and SuSE's at least, I think) have had the O(1) scheduler backported to them as well. In fact, if you're running near enough any current 2.4 kernel other than mainline, you get the O(1) scheduler and your share of scheduling fairness.
The new scheduler is also a fundamental basis for Linux 2.6's new NPTL 1:1 threading, which has so far proved spectacularly (record-breakingly?) fast. Hmm, on second thoughts, perhaps I probably shouldn't mention threads and FreeBSD in the same post. I mean, isn't this the same FreeBSD that's still waiting for a single half-decent pthread implementation? Oh well, better hope 5.0 is out soon...
Then run more conservative programs to go slower. In the end you go the same speed as everyone else but spend tons of useless cooling solutions.
Hmm.
Slashdot Patriotism: We Support our Dupes!
My question is simple.Being faster does not necessarilly mean that is better.I would expect the new kernel to be more versatile and tuned with less powerful platforms in mind(e.g. Strong arm or other embedded system solutions).Computers are nowadays smth like swiss knifes.In the future there will be specific hardware for specific tasks and linux kernel must be there! The need for a project like the GNU Hurd must alert linux kernel developers.
Make things as simple as possible but no simpler.
A prior employer of mine ran 486/33's (and maybe 386's, not sure) as nameservers, and also as webservers too I think. Biggest complaint was compile-time for apache/etc
I'm looking forward to the network failover and I/O failover features. The Device Manager looks pretty, too. But, when are they going to provide an friggin' LVM? Optimizations are great, but I want features, Damnit!
OK, I have had it up to here with all this FreeBSD worship. After putting up with this for a long time from one of my good friends who happens to be a BSD bigot, I made the mistake of wiping out my Mandrake 8.2 and installing freeBSD on my box.
After a few months of that, I am back back in Mandrake 9.0 with relief and no regrets. Why?
1) I found that, for the things that I do, FreeBSD offered no advantages at all. Performance and stability was no better than Mandrake 8.2. In fact, under heavy loads, my experience is that Linux 2.4.x is much better. (I run lots of octave math simulations and lots of fortran number crunching programs, often several at a time. )
2) For people used to working with linux, there are lots of annoyances to working with FreeBSD. I missed the convenience of RPMS. Many of my favorite programs did not compile properly.
3) When pitch came to shove, my friend had no suggestions as to why the FreeBSD install did not perform as well as linux, except to tell me that I must be mistaken in how well the linux install performed! Duh!
Now, maybe under some circumstances, it is probably true that FreeBSD does outperform linux. But I could not care less. For the work I do (mostly on the desktop, running simulations, running mozilla and xine), linux is demonstrably a better system than FreeBSD.
Magnus.
Shouldn't benchmarks of the kernel start including this setting? I'm assuming the default (100) since it's not mentioned, but isn't it worth running test with several different settings? It's affect may vary by load, cpu's, etc...
-T
http://unmoldable.com W:"No one of consequence" I:"I must know" W:"Get used to disappointment"
But, when are they going to provide an friggin' LVM?
Err... Linux 2.4 has included Sistina's LVM for some time. 2.6 will have a more generalized kernel interface, the Device Mapper, that will allow both version 2 of the Sistina LVM, and the IBM alternative, EVMS, to be built on top. Or at least, that's what Linus seems to have decided on for the moment.
The Device Manager looks pretty, too.
I think that perhaps you are confused. Device manager? And a pretty one, at that? No LVM? Hmm, ok. Maybe you need some spelling help: L-i-n-u-x spells Linux, not Windows 2000. ;)
I'm using P75 as desktop.
/proc/cpuinfo
running wmaker, XFree86 4.2
galeon 1.2.x as browser.
pine for mail with fetchmail + sendmail
each time I want to compile stuff,
just "nice blablabla"
[sebol@localhost sebol]$ cat
processor : 0
vendor_id : GenuineIntel
cpu family : 5
model : 2
model name : Pentium 75 - 200
stepping : 6
cpu MHz : 74.705
-- Hasbullah bin Pit (sebol)
I mean, if it were *just* about technical cleverness, the story would be over. Okay, Linux is clever. Film at eleven.
But there's also the crusade out there to *prove* to "them" that Linux can hack it in the enterprise, that it stacks up against Solaris and Windows NT. Space in server rooms is at a premium, and it's a victory for open source whenever a rack slot gets filled with a linux or bsd box.
There's also the cherished open source community belief that "sharing" and openness comprise a valid business model. In light of that, marketing and dollars are extremely important. The marketplace is a democracy, and every dollar is a vote.
(gasp)
And that's all I have to say about that.
I wonder why Microsoft advertizes in Slashdot.
/. readers use IE, if I recall the recent topic on the subject. Given that, it's not a stretch to assume that the majority of /. readers use M$ products regularly.
Most
None of these stats seem to cover simulated heavy multiuser/multithread activity. That's what's key as far as I'm concerned. One of the major flaws in Linux today is the scheduling of user processes and file I/O (not sure about networking I/O, but it seems okay from simple observation). There are still severe process/thread starvation problems in the 2.4 kernel which are supposed to have been addressed in 2.5, but I've never seen a really good, real-world performance test to prove it. Until those problems are solved, Linux won't be useful for realtime server work other than web service.
In case you're wondering, no, I'm not a troll. I've done *extensive* testing in this area. So have others, which is why they've been working hard on scheduling.
Run-on Sentences When Will People Learn?
Linux 2.6: 12-inch steaming love-rod
Linux 2.4: 10-inch muscle of love
Windows XP: 3-inch disappointment, but hey, she's the one who wanted to be a virgin until her wedding night...
Macintosh OS X: Vagina
Not much I'd say. Take "process_load". There are a couple of processes running, some of them called "background load" by Con, the others called "workload".
The workload is a little faster in 2.5, the background load a lot slower. Why should this be better? The kernel compile ("workload") could just be the load YOU are running in background.
These benchmarks are certainly extremely useful for developers, telling them how behaviour in a multi-tasking situation changed. But they don't serve for a "2.5 is so much better/worse than 2.4" (at least not without careful interpretation).
Q3 engine based games like RTCW already support this.
Thanks, dear AC, for pointing that out. In other words, id has already ushered in the era of multi-cpu gaming, and there's no question at all that dual cpus get you more bang for the buck than a single high-end processor, twice as fast. At least this goes for id games, but imho, where goes John, goes the entire 3D game industry in the long run.
So now the interesting question is: when do quad machines hit the sweet spot on the cost/performance curve? I'll go out on a limb and guess "quite soon", that is, 3 years or so from now, and that is entirely due to the fact that AMD has already integrated most of the glue you need for SMP onto the Hammer. Now it's mainly a matter of waiting for quad mainboards to start hitting the overclocker market. Yes, there is an overclocker market, and there are companies serving it.
Quad Hammer for gaming anyone?
Have you got your LWN subscription yet?
So they need adverts touting what they already have?
A Government Is a Body of People, Usually Notably Ungoverned
Every major kernel release has this debate..
It has a bunch of imporvements optomisations etc.
It's got newer faster better ways of doing the same old things.
But... It's doing more than ever before.
It COULD be faster or it could be slower.
Or it could be exactly the same as before.
The real answer is "Wait and see" the rest is just talking...
I don't actually exist.