Linux Kernel Benchmarking: 2.4 vs. 2.6-test

frooyo pastes from kerneltrap: "Cliff White recently posted some re-AIM multiuser benchmark results comparing the stable 2.4.23-pre5 kernel against the 2.6.0-test5 and 2.6.0-test5-mm4 development kernels. In his conclusion he makes reference to earlier scheduler tests posted by Mark Wong saying, "Short summary: we mostly rock.""

Comments

Comment removed

[account_deleted]

Comment removed based on user account deletion

SMP

[Doesn't_Comment_Code]

The SMP code (written by Linux developers by the way) is supposed to be kicked up a notch in the new kernel. That's what I've heard anyway. I'd love to see Linux being the best OS for multiple CPU scaling.

That will help everyone from the server market, to me when I save up enough for a two processor motherboard.

Re:SMP

[Brahmastra]

Hyperthreading is another factor to consider. I wonder if there are any HT optimizations

Re:SMP

[Arker]

I've got nothing against Linux improving at SMP in essence, but there is something very bad going on here it seems to me. Notice that while the new kernel 'kicks ass' on SMP systems, on uniprocessor systems the 2.4 kernel is the one kicking ass. Anyone benchmarked 2.4 against some of the pre-SMP kernels on a uniprocessor machine?

Face it, the vast majority of users are uniprocessor, and kernel performance is more of an issue on lower-end machines. Improving performance on big multiprocessor boxes is fine by itself, but not when it harms uniprocessor performance. I'm not a kernel hacker, but I've read many people that this would not happen, that the SMP code would not hurt performance on a uniprocessor machine when the kernel is compiled without it, but that's obviously not turning out to be the case. Anecdotal evidence, at least, suggests that this performance degradation has actually been going on for quite some time, at least back to when SMP code first started being added.

I'm not sure what all the factors here are, so naturally I'm not going to tell you the solution, but it certainly looks like a potential problem that should be discussed. Hopefully someone with more specifics than I have can chime in...

Re:SMP

[Valar]

No, because that's OpenBSD. Duh.
Oh wait...

Re:SMP

[Horny Smurf]

he meant "kicked in the crotch". To test and see if it's genuine uneuchs.

Re:SMP

[GooberToo]

Yes, there are. The scheduler is fully HT aware. It seems that many of the SMP and numa optimizations also apply to HT'ing as well. As such, the developers have been working hard to support it.

Worth noting, however, it's not uncommon, even for a system that fully supports HT, to see a noteworthy performance drop when HT is enabled. Seems many new systems come with HT disabled in the BIOS for this very reason. Granted, I'm not 100% that's not a Window's specific issue rather than a broad-board HT issue, but something to keep in mind, nonetheless.

Re:SMP

[blakestah]

Notice that while the new kernel 'kicks ass' on SMP systems, on uniprocessor systems the 2.4 kernel is the one kicking ass. Anyone benchmarked 2.4 against some of the pre-SMP kernels on a uniprocessor machine?

Yeah, they missed an important test - latency for interactive processes. A lot of scheduler work went into improving this, and it makes a huge difference when you have large memory processes working hard.

This aspect is improved across the board in 2.6, as well as the SMP issues. Sure, the uniprocessor machine may be a little slower, but response latencies in X are a lot better, and this makes more of a difference to users.

Re:SMP

[pmz]

I've got nothing against Linux improving at SMP in essence, but there is something very bad going on here it seems to me.

I don't understand...scalability to hundreds of CPUs will provide much penis enhancement for geeks everywhere (even the ladies).

Re:SMP

[Arker]

This aspect is improved across the board in 2.6, as well as the SMP issues. Sure, the uniprocessor machine may be a little slower, but response latencies in X are a lot better, and this makes more of a difference to users.

I beg to differ. I couldn't care less about X, I haven't even used it in over a year. Like the vast majority of Linux boxes, mine runs in console mode only, and on a single processor. I, and the rest of the world that uses it like this, find it hard to see anything to get excited about in 2.6. It could be that misty thing that happens with your memory over time, but it certainly seems like my first linux box (slack 1 on a 386-25) had better performance than I get now with substantially more powerful hardware in fact. At the very least I'm certainly not seeing any dramatic improvements. I used to upgrade kernels as a matter of course, but now I just don't care, unless there is a security update involved. If it weren't that necessary maintainence work (security patches, in particular) were suspended long ago I'd be tempted to swap in a fresh drive and give it a try, in fact.

Like I say, it's nice to see SMP support getting better, I've got nothing against it, or any of the other features that have been introduced over the years, but when it starts interfering with performance on the machines that need performance the most, and coincidentally the ones that account for the vast majority of boxes running Linux as well, there is obviously something going wrong. Maybe the config scripts need more work, maybe there is nothing to do but fork large sections of the kernel, I don't know, but if Linux keeps getting worse at fulfilling its bread-and-butter role it will eventually have to be replaced with something else.

Do you really want to see Linux running on Minicomputer class machines (the kind that private citizens usually can't afford) exclusively, at the expense of being usable in its traditional role of turning cheap old boxes on their way out the door into powerful and stable servers? Does Linus?

I don't, and I predict there are enough programmers out there that agree with me that if the trajectory continues we'll eventually see either a kernel fork, or a mass migration to *BSD, or both.

Re:SMP

[Vellmont]

Well, I don't think you can conclude that the SMP changes to the kernel are what's slowing down the 2.5 Uniprocessor performance vs 2.4 kernels. There are many other changes that took place (low latency and an improved scheduler come to mind) that aren't SMP related.

Obviously the SMP performance has been improved, and there was a lot of potential for improvements looking at the 8x test. Another way to interpret the results would be to say that the other changes decreased performance across the board on SMP and Uniprocessor systems. The SMP improvements in SMP machines more than made up for this added cost and improved raw performance on SMP machines.

Hopefully the performance loss on Uniprocessor machines can be decreased or eliminated. Even if it's not, I think you need to remember that raw performance isn't the be-all-end-all thing that's important. 7% is pretty small in the grand scheme of things where processing speed is doubling every 18 months. Responsiveness and better scheduling that doesn't starve processes is more important than a 7% performance decrease IMO, and you don't get that from faster processors.

Re:SMP

[be-fan]

If earlier versions of Linux are good enough for your old 386-25, why not keep using it? As Linux scales up to bigger and better machines, there is going to be some cost at the low end. Its a matter of priorties. I, for one, use Linux as my main desktop OS. I care a whole lot about the improvements in 2.6.

Re:SMP

[ocelotbob]

The issue with hyperthreading's performance drop comes from the fact that both logical threads are contending for the same cache. Thus, code has to be rewritten in an HT-equipped machine to only use half the cache it normally would take. Thus, in your typical 512k cache machine, you've got to profile your loops, etc, so that it only uses half that cache. The typical program is not written with specific requirements on how much cache they use, thus they throw as much data as possible into cache, causing the two logical threads to fight over the cache, degrading performance. Pretty much any program will act this way, unless compilers get smart enough to have compile-time control of a cache model so that one can recompile everything to take advantage of HT.

Re:SMP

[GooberToo]

Great response! Thanks!

That explains why I remembered reading about "HT aware" applications but I didn't want to mention that because I didn't remember the context at which it applied. Furthermore, and perhaps worse, I simply couldn't remember what "HT aware" meant. You response brought all of that home again!

Excellent! Thanks!

Re:SMP

[eMilkshake]

Well, why not support SMP by default? After all, Intel is going that direction with their uni-CPUs -- making them appear as two. Perhaps that is their permanent direction.

If so, then shouldn't everything be written assuming it will run on two processors, since that's all we'll have in a few years?

Re:SMP

[Arker]

If earlier versions of Linux are good enough for your old 386-25, why not keep using it?

Was - the 386 is long gone, although I have a great little 486 doing some minor chores right now. And then answer to your question was in my post, if you'd only read it - maintainence, mainly security updates. In comparison to proprietary alternatives, of course, Linux is great on this issue, but no distro and no kernel is maintained forever.

And just to be clear, Linux was my main desktop OS for several years too, and I'm not knocking it at that. The only reason I haven't used it for that is that my main desktop for work is now my TiBook. The windows box is and has always been a gaming machine. For every purpose the best tool... at the moment. I'd actually rather run LinuxPPC on my TiBook, but the applications I need for work won't run on it, so there you go.

But considering that the vast majority of Linux boxes are, and are likely to continue to be for the forseeable future, headless uniprocessor servers, doesn't it make more sense to, if not optimise for those, at the very least take care not to de-optimise for those installations? That really seems to be what's been happening.

Re:SMP

[whereiswaldo]

Pretty much any program will act this way, unless compilers get smart enough to have compile-time control of a cache model so that one can recompile everything to take advantage of HT.

I'd bet that Intel's tools are this smart. Check out their VTune software as well, if you're looking to optimize for Intel's latest and greatest processors.

Re:SMP

[jelle]

This is where I can remark that Intel already effectively has two processors on a chip with their SMT Xeons, and that both AMD and Intel have made references to introducing even full multi-core CPUs. You don't need two CPU chips to need SMP anymore.

I wouldn't be surprised if the 'standard high-end desktop' will have a need for SMP in the near future because of the processors themselves.

Re:SMP

[jelle]

"Like the vast majority of Linux boxes, mine runs in console mode only,"

Where did you get that statistic?

Re:SMP

[Brahmastra]

One issue with HT performance is in the case of Floating point code. There is only only FPU in the chip. Another issue with HT performance is when there are tight loops in the threads. Intel recommends using a "pause" instruction when there are idle loops. Not using a pause instruction tends to make all the threads contend for the same functional units, decreasing performance.

Re:SMP

[jelle]

About the majority of linux boxes being headless or not, between his post and yours it weakened from a multiply stated strong fact to an assumption.

Even if the total desktop share of Linux is small in percentage compared to that other desktop OS, that still means a percentage of a much larger number of PCs.

If the "vast majority" of boxes were headless servers or cluster machines, then don't you think that there would be a lot more active linux distrubutions, forums, reviews, websites, etc, about issues for such setups. But quite a large portion of the activity in the largest Linux distributions and many linux forums and websites are about new or improved X11-based graphical desktop environments, graphical libraries, and graphical programs. Why would so many people care about gnome/kde, mozilla/konqueror/opera/firebird, openoffice/koffice/gnome-office, gimp/gnumeric/sodipodi/kivio/abiword, ximian, xfree86, mplayer/xine/libavifile/sdl/xv, mythtv/freevo, libfreetype, wine/winex/transgaming, etc. if that only represented the vast minority of Linux?

I wouldn't be so sure that the _vast_ _majority_ as the original poster states more than once is headless.

Besides, even for servers or other headless boxes, there may well be loads similar to an X server process combined with other processes that require a low latency (interactivity).

Re:SMP

[bill_mcgonigle]

Face it, the vast majority of users are uniprocessor, and kernel performance is more of an issue on lower-end machines.

Actually, I've found the opposite to be true.

Sure, application responsiveness is important on a desktop machine, but there's nothing like a few hundred concurrent users beating on a system to start to notice the kernel getting in the way of applications trying to do their jobs. If you're going to have that many users, you're going to have an SMP machine with plenty of hardware, and the kernel needs to get out as fast as possible so the hardware can be utilized.

Re:SMP

[blakestah]

Linux is built to satisfy many different design criteria. Mainly, it seems that whatever pisses off developers the most gets worked on.

Lately, that has been latency issues. Several patch-forks developed for pre-emptible kernels and low latency issues, and kernel developers didn't like latencies for X and xmms and video playing. So, they worked on it, and found a small uniprocessor performance hit accompanied a vast improvement in scheduling and latency.

Most linux servers are not CPU limited anyway. Mail servers and DNS servers and web servers are not so often CPU limited, and when they are, a faster machine and/or SMP is a better solution than a kernel with the prior latency issues.

Basically, the kernel is not optimized to get the most out of a single CPU situation. If that is REALLY important to you, it may be worth evaluating different OSs (personally, I'd find it a lot easier to buy the latest speed-demon machine and still use linux, but that is just me).

Re:SMP

[Arker]

Web servers with even a modest amount of dynamic content are very often CPU limited.

'The latest speed-demon machine' on your desktop is not.

GREAT

[proj_2501]

now i need another CPU to increase performance!

Re:GREAT

[Anonymous Coward]

In Soviet Russia, we had to increase performance in order to get another CPU ...

Re:GREAT

[stevezero]

ok, that was funny. I usually get blase(insert accent aigu) about Soviet Russia jokes, but that one made me laugh, sir/madam/beast/cronjob.

Re:Great

[110010001000]

"It sucks to loose"

It sucks to not know how to spell "lose".

Re:GREAT

[richie2000]

Your designation of the AC made ME laugh. :-D

novel idea.

[justin_w_hall]

Go figure. An OS that gets faster with each version.

Re:novel idea.

[lightsaber1]

Now if only microsoft would pick up on the idea...

Re:novel idea.

[stratjakt]

It's only faster if you have 8 CPUs, your single proc desktop box will be slower.

Which just reaffirms my belief that linux is becoming ever more firmly planted in the server world, and desktop linux is still just a hobby for the most part.

Re:novel idea.

[Otter]

That's Apple's specialty -- introducing new hardware (PowerPC, AltiVec) and gradually catching the OS up to it. The early PPC system (System 7.5?) had tons of emulated 68k code in it that was gradually removed with each update and replaced with native PPC code.

Re:novel idea.

[norton_I]

2.6 is supposed to be fully preemptable, which should make lots of latencies decrease, leading to better interactive performance on a desktop, even if the overall throughput is lower. What this benchmark shows is that linux kernel 2.6 is a slower uniprocesser server than 2.4. While that is too bad, it doesn't really say much about desktop linux. I just installed 2.6-test5 on my (2 cpu) desktop, but haven't really had time to evaluate its performance relative to 2.4.

Re:novel idea.

[Valar]

Ah, but what of my dual processors with HT? That's four logical cores. As more and more commodity CPUs start to use stuff like HT, performance of OSes written for MP will increase on the desktop. Anyway, I'm willing to take a little bit of a speed hit if it brings sufficiently valuable features with it.

Re:novel idea.

[GooberToo]

That statement simply is not true. Granted, you can always find some corner case where the workload is going to be slower between releases (2.x or 2.6), however, as a rule of thumb, 2.6 should still be a huge improvement for even uniprocessor users. Best yet, many, many parameters of the kernel and scheduler are tunable, so, you can always adopt the kernel to work best for your specific workload needs.

While it's true that they are working hard to significantly improve Linux for the server room, by far, they have never lost site of the uniprocessor user. Remember, there is nothing wrong with tuning the kernel for your uniprocessor needs, and specific workloads. They just can't do that when they are benchmarking because it would skew the results, invalidating them. They are not only trying to measure how their improvements effect the overall system, but, what makes for sane initial defaults, which are reflective of a general purpose and broad workload. If you understand what you are doing, there is not a reason to believe that you can't greatly improve things for your specific uses and workloads. It's important to keep all of these in mind when talking about these benchmarks. Furthermore, you should fully expect your favorite distro to come with tuning presents which reflect a targeted workload (file/print server, workstation, database, web server, etc.).

Keep in mind that the benchmark you looked at represents one category of many different types of workloads. So, for that specific workload, it may of been slower, however, that workload my not represent anything you do with your computer. Remember, other types of workloads are significantly faster. One last note, remember, performance is the classic trade off with lower latencies. It trades responsiveness for raw throughput. If, on a uniprocessor workstation, you only see a -7% drop in performance and latency is greatly reduced, chances are, not only will you never notice the loss in performance, but you'll be praising it for how well it works with your mouse, monitor and keyboard (if feels better and makes you a happier user).

Just some food for thought.

Re:novel idea.

[Karn]

Wrong.

One benchmark used for Linux kernels is hammering a system while playing an mp3 to see if they can get it to skip. Low latency is mostly a desktop feature, and the 2.6 kernel is going to have much improved latency.

Other portions of Linux have changed, and may not initially outperform 2.4, but if you think this kernel isn't going to be a dramatic improvement over 2.4 for desktop users and servers, and if you think the kernel developers aren't taking the desktop into consideration, you are mistaken.

Re:novel idea.

[be-fan]

Desktop Linux kicks ass. With 2.6, interactivity on an unloaded system is close to WinXP, and on a heavily loaded one (the steady state of my machine :) kicks XP's ass all over the place.

Re:novel idea.

[Ramses0]

Check this out:

Take a pentium 800mhz from 2-3 years ago. Compare it with a pentium 2.4ghz from this year. Thats an increase (for UP people) of 300% (three times.) Don't forget to subract your 7%, so you're back to a 293% relative performance increase (not really, but shut up).

Now, increase SMP performance by 10% or whatever. It makes sense. For the hobbyist, 7% performance degradation per annum is not going to make a difference, so long as there are significant improvements that can keep linux relevant.

I've heard of a project called "TurboKDE" which is taking KDE1.0 and hyping it up, where the KDE1.0 runs like 2-3 times faster than latest ones b/c of increasing complexity.

If you're running your 300mhz P2, then run a 2.2 kernel, if that workload is better. USB support is (I believe) back-ported, so you don't really have too many excuses not to. Can't buy it in stores? Don't need to, download it from kernel.org. Buy from CheapBytes.

Side-note: The internet is not permanent! When searching for demos of old video games (like SystemShock2) so I can try them on WineX, I ran into so many dead links it's not funny. Nothing replaces owning a personal copy of something on a CD.

That is all. :^)

--Robert

woo

[grub]

If you thought SCO was mad over 2.4, just wait until they make up evidence for the 2.6 kernel!

Re:woo

[syle]

First time I've laughed out loud at an SCO joke =P

Some explain to me in layman terms what the hell

[zymano]

What the hell all those numbers mean ?

From a Gaim user

[metroid composite]

Well, I use Gaim constantly. Come to think of it, I haven't bothered to figure out how to connect to AIM through a Windows machine. I will say that MSN Messenger is not something to compare it to; lots of people have AIM accounts and not MSN accounts. Though, perhaps I have an old model, but I have some problems like links not working properly, not accepting file transfers, and in chats "Ctrl+C" brings up the colour menu...so no copy and paste.

Re:From a Gaim user

[Elfan]

The windows port of gaim might work ;-)

Re:From a Gaim user

[Anonymous Coward]

but it doesn't. GTK+ for Windows is very very buggy.

Re:From a Gaim user

[Anonymous Coward]

I use Gaim 0.68 on w2k and FreeBSD. It works quite well.

Re:Real world please.

[Anonymous Coward]

OT, but I'm pretty sure I've never seen "real world" and "instant messenging" in the same sentence. Except maybe with the accompanying phrase "no relation to".

Not to be a n00b...

[Visaris]

Not to be a n00b, but I can't make too much sense of the benchmark the story linked to. Could anyone give a short simple little explanation of what it means? Thanks so much!

Re:Not to be a n00b...

[MrEd]

There has to be a happy medium between this review's tables of figures and Tom's Hardware's chrome graphs.

Re:Not to be a n00b...

[NtroP]

Not to be a n00b, but I can't make too much sense of the benchmark the story linked to

You actually READ the article?!? Man! You ARE a N00b!

Re:Not to be a n00b...

[gyrovague]

The workload simulates a multi-user system by running an increasing number of users. Each user does a list of tasks. We keep adding users, until the load reaches a max. The score shows tasks per minute, and peak user count. Bigger is better. http://www.osdl.org/stp

Re:Not to be a n00b...

[Slime-dogg]

heh. A response to a "n00b" by someone who's even "newer" to /.

Re:Not to be a n00b...

[IpalindromeI]

Ah, but "newer" does not necessarily mean n00ber. You see, NtroP, with his punny nickname, nonsensical but plausible sounding sig, and use of all-caps and exclamation points, has obviously studied harder to become one of the Slashdot 31337. He has teh skillz. However, we can see that Visaris completes full sentences and actually read the article. Clearly a n00b.

Re:Not to be a n00b...

[quigonn]

Ah, 6-digit-users discussing about being a n00b or not. you're all n00bs, because your UID has 6 digits.

Re:Not to be a n00b...

[clem]

you're all n00bs, because your UID has 6 digits

Yeah, whatever, Mr. Fivey Digits.

Re:Not to be a n00b...

[quigonn]

*lol* I expected something like this.

Re:Not to be a n00b...

[Slime-dogg]

I don't recall ever proclaiming my number of digits. I was merely commenting on the reverse-n00bness going on.

timeline?

[NumLk]

Seriously, its great and all, but when will it be ready for the masses? I.e. the holy 2.6 release? For us, loading a beta (or even alpha) kernel is something that we can do in our sleep, but look at it from this perspective: all of these improvements will only really make an impact once developers can write applications specific for this environment, which requires, at a minimum, an official release.

Rock?

[TheLink]

It's only significantly faster if you have 8 processors.

Whereas it is 7% slower if you have one processor.

I suppose they'll have uniprocessor version which runs faster? Lots of people have uniprocessor pcs.

Hyperthreading doesn't really count.

Re:Rock?

[kasparov]

Where did you see that it is 7% slower with one proc? What is 7% slower than what with one processor? Not trying to disagree with you or anything, I just didn't notice anything in the article and was hoping for link.

Re:Rock?

[arkanes]

It might very well be slower than 2.4, but "feel" faster. The low latency stuff can improve responsiveness at the expense of performance.

Re:Rock?

[borgboy]

Hyperthreading doesnt really count? I didn't see the benchmark that you derrived that little gem from. Any hard data?

Re:Rock?

[molarmass192]

I suppose they'll have uniprocessor version which runs faster?

I'm trying not to read too much into this benchmark. The new kernel preemption in 2.6 will make Linux "feel" faster even though it may be slower given a long running continuous task to chew on.

To counter balance that, I'm assuming that the focus right now is on stability rather than optimization. I'd hope that any performance gap with the 2.4 series would be closed shortly after the 2.6.0 release. What was the situtation like between 2.2 and 2.4?

Re:Rock?

[Perl-Pusher]

The author makes reference to it at the top of the page before the numbers. The actual figures are in the full benchmark link to in the message.

Re:Rock?

[Jeff DeMaagd]

Linus' tactic of not doing much to improve multiprocessing support hurt the high end, at the dubious claim that it had to hurt the low end.

I've thought for a long time that you want different schedulers available for different scales of multiprocessing. Heck, even Windows has different "drivers" for uniprocessor and dual processor machines for W2K Pro.

Re:Rock?

[GooberToo]

Linux, more or less does this too. When you compile out SMP support, it effectively changes the resulting code so as to no longer be the same beast. In doing so, it is supposed to save a lot of overhead. I didn't notice if the benchmark results were compiled with SMP support or not, when run on a uniprocessor.

Anyone notice?

Re:Rock?

[scosol]

I dunno- it sure doesn't "feel" faster to me on my Transmeta (2.4.20 VS 2.6B9)

Re:Rock?

[CAIMLAS]

My understanding is that they've designed 2.6 with specific interest and attention spent on speeding up the kernel for desktop users. They've decreased latency and such, so that 7% slower on a server-related task will likely not translate over to desktop use.

Re:Rock?

[GooberToo]

> Is that still true with the Preempt changes?

I'm not exactly sure what you're asking? You asking if you get a different animal if you compile out the preempt code too? Meaning, higher performance at the cost of higher latency? AFAIK, the answer is yes.

> Also with hyperthreading, psuedo-SMP is really a lowend feature now.

The problem with that is, enabling SMP support, of which HT is part of, requires additional locking and more overhead to keep things straight in the kernel. To makes matters worse, HT really isn't turning out to be the great-all-around feature that everyone has been looking for. Depending on the application mix you're running, with HT enabled, you may actually see a reduction in performance because of HT. Mix in the additional overhead of having a SMP kernel running on a uniprocessor machine, you may be looking at a significant loss of performance.

As someone just reminded me in another thread, the problem is that you have too many applications fighting for cache, which causes many cache stalls. That, in turn, makes for significant performance loss. Some tests I've seen indicated as much as 30% drop in performance when HT was enabled; with 10%-15% loss the norm. This is the reason why HT is often disabled in the bios of new systems. Of course, if you happen to run a very HT friendly mix of applications, then you may realize a noteworthy increase in performance; something like 10-30%, IIRC.

Long story short, unless you know your application mix is very HT friendly, chances are, you're going to be bleeding if you enable it.

Re:Rock?

[TheLink]

So can some racing stripes and a larger exhaust pipe. ;)

But seriously, I know what you mean. Better interactivity etc.

Re:Rock?

[TheLink]

There are a few benchmarks on that elsewhere. Overall it's hit and miss - you win some you lose some.

Seems to me like having to optimizing for different architecture processors at the same time - because sometimes you have X FPUs/ALUs/etc and sometimes you don't. So if your optimized code uses most of a P4 there'll be problems when other code runs at the same time. You're probably better off running optimized programs on a uniprocessor setup and do a switch every x milliseconds, than to pay the scheduling penalty at a lower level.

Hyperthreading should be OK if you run unoptimized code - code that doesn't use most of the CPU's processing units. It may be good if you have background AV and do lots of GUI work, but I haven't seen any benchmarks for that.

BTW I ran two "openssl speed" on dual SMP server and the kernel put two processes on ONE CPU, coz it thought all 4 "CPUs" were the same. You could see it gradually migrating the processes to the wrong place! Ugh. Probably fixed in more recent kernels.

User Experience

[the_crowbar]

I run 2.4.22 at work and 2.6.0-testX at home. The 2.6.0test(vanilla) series feel much more responsive, especially in X. I have not done any real benchmarks of my systems, but after working with 2.4 all day 2.6 seems to fly.

Just my observation
-the_crowbar

Re:User Experience

[broeman]

I get the same feeling ... especially with 2.6.0-test5 ... test4 had some difficulties with XFree86 (mouse and windows would flicker or be quite inresponsive). I have no idea if it is faster, but I really don't care. The responsiveness is a great win, and the easiness of cryptoloop, but I thought they had stopped with SCSI-emulating IDE-CDR, this really annoys me.

Re:User Experience

[Spuggy]

The option is still there for the SCSI emulation (I'm assuming this will go away in the future), but you should have no problem using your drive as a pure IDE drive now w/ the newest versions of cdrtools & cdrdao.

I'm running in IDE mode only with no issues.

Re:User Experience

[broeman]

ok, I haven't even tried ... just noticed the option still were there, and felt like not going through that trouble again. Cool, lets burn them! :o=)

Re:User Experience

[Kashif Shaikh]

But 2.4.20 /w Con Kolivas's patch set(/w 1000hz tickrate) is much more responsive than 2.5.75.

There's very little window shaking and mouse slowdowns. Still, its not resposive as (*gasp*) Windows, but its getting there.

Hopefully, 2.6.0-testx will get better.

Re:User Experience

[DaveAtFraud]

Agree. I'm running 2.6.0-test5 on a dual Athlon 2400+ system and it flies compared to a 2.4 kernel. I started running development kernels with 2.5.22 and have been very pleasantly surprised by how stable the development kernels have been.

Re:User Experience

[Cyn]

So - after working for 8 hours a day in your day job, you come home to a relaxing evening of free time where it seems to just FLY by. I'm not entirely sure this experience can be directly compared, perhaps if you could try 2.6 during the (drudging?) hours of your workday? :)

Re:User Experience

[the_crowbar]

If only it were 8 hours a day. My payweek ends today and I have some 60-65 hours so far.
Heh! At least I have a job.

-the_crowbar

Re:User Experience

[devnullify]

I've been (trying) IDE mode for the past few days...and every CD I burn has some sort of error. Audio CDs have messed up cuesheets, data CDs have corrupt files. Load ide-scsi up and it works fine.

Perhaps I'm just using the wrong driver, but it's the same one that I use with ide-scsi.

Re:Real world please.

[tomhudson]

AIM (now at version 7) is not an instant messanger client. It's a benchmarking tool. Click on the link in the story to see what it is/does/etc.

Better comparision

[ajiva]

A better comparision would have been against Solaris x86. Solaris scales very linearly with every added processor.

Re:Better comparision

[tempest303]

Jonathan Schwartz? Is that you? ;)

Re:Better comparision

[rutledjw]

Are you sure?!? Solaris / SPARC does, but I thought that Solaris x86 was as totally different beast.

When we did some speed tests on Solaris x86 vs the early 2.4.x kernels about 2 uears ago (a while granted), Solaris x86 was a DOG. They may be trying to clean it up now, but even then they admitted it was basically an afterthought.

I've seen a TON of different hardware / OS configs, but I know of only one shop who used Solaris x86. They used in dual CPU machines only.

Maybe I'm wrong, but my impressions of x86 Solaris were not positive...

Re:Better comparision

[adrianbaugh]

Why would it be better to compare linux to solaris if you're trying to find out how linux performance is developing? How solaris performs is totally irrelevant, except as an idea of what other people can do - it has nothing to do with understanding the effect of changes made to the linux kernel.

2.4 vs 2.6

[Doesn't_Comment_Code]

I assume that when they say the 2.4 Kernel outperforms the 2.6 on a uniprocessor computer, but not on a multi processor computer, that they have recompiled the kernel for each hardware environment.

This struck me as strange, because when the kernel is compiled without SMP support, all that code is left out. So it doesn't seem like the 2.4 should outperform the 2.6 on one cpu.

Does anyone know why this might be?

Re:2.4 vs 2.6

[iggymanz]

heh, it looks like 2.6 has great new features for all types of machines, but poorer overall performance for the normal desktop PC. The price of being scalable?

Re:2.4 vs 2.6

[Dan Ost]

Perhaps the low-latency fixes add overhead. 2.6 might feel faster
because of this but might actually run slower.

Re:2.4 vs 2.6

[tmasssey]

By definition, with the speed of context switches and other overhead the same, a system with "low-latency" switching (switching faster between interactive jobs) will be slower. It switches more often, therefore wasting more cycles with switching overhead.

Of course, there is the possibility of trimming cycles from the process of switching contexts. Linux, though, already had that pretty low. That's why Linus is so resistant to shared-memory, shared-context threads: the cost of processes is so low that the benefits are small. However, some speed was gained in context switches.

Overall, though, more switching means slower performance, even though the user feels like the system is faster. It's not faster. It's actually slower. It's just more responsive.

Confused yet? :)

Re:2.4 vs 2.6

[Feyr]

easy enough to check, disable the preemptive code and do a new benchmark

my own experience with test5 shows me that it has issues with memory management/swap. the machine was completly unuseable when all the memory was used up

Re:2.4 vs 2.6

[iabervon]

The tuning being done for 2.6 is primarily based on reducing the latency of interactive tasks in the face of intensive background tasks. That is, your normal desktop PC will be a better desktop at the cost of being a worse workstation (your windows move smoothly, your keyboard and mouse respond instantly, your music doesn't skip, but your compiler may take longer).

This is largely due to people finding way to measure the sorts of performance you actually care about for desktops. This is at the expense of other benchmarks.

This benchmark is more relevant to servers, and shows improvement on large servers and a bit of degradation on small servers.

Thanks SCO.

[EDA Wizard]

Looks like that 1970's UNIX code really increases performance for SMP P-III's.

Now we can appriciate the forsite that our Unix fathers had when developing Xeon SMP code in the late 1970's.

I'm a bit leery.

[devphaeton]

"the general trend in the metric indicates everything has been improving, so I think we rock."

For some reason, the scheduling seems to get more and more choppy (in that i've noticed) with every iteration of 2.4.x kernel. Currently i'm on 2.4.22, and while i don't have any specific tests, numbers or statistics i'm noticing some issues.

Easiest way to reproduce it is to have the machine do something cpu intensive, such as mkisofs, cdrecord, bzip2 some huge file, cp anything large, installing (via aptitude) or even the "Reading Package Lists...." stage of apt-get update.

Oftentimes, the machine will become unresponsive for about 3 seconds at a time, then jolt back up to speed, then pause for 3, on and on. Even after the command line returns the prompt, or gkrellm's cpu and proc krells show that everything is all done, i will still see lag in responses from the kb, mouse, or whatnot off and on for about 10-15 seconds.

I've gone over my kernel config and tweaked a few things here and there but with no change. I can back down to a 2.4.18 kernel and it's not as bad. Going down to a 2.2.x kernel completely solves the problem, but of course will bring its own issues with some of my newer packages (such as gcc) and a few pieces of newer hardware.

A friend of mine and I have gone over this (on my machine and his) and he experiences a lot of the same issues i do.

Mind you, i'm not complaining. I'm very grateful to all the developers of the world that i even *have* a linux system to run. But this is something that makes me more excited about the kernel 2.6.x series. I haven't tried one out yet, but from what i've heard and read, it should be awesoe. :o)

Re:I'm a bit leery.

[blonde rser]

Since it seems your running debian and all those cpu intensive operations are also hd intensive operations have you checked hdparm -d /dev/hda . I know it is simple but it is so simple that I forgot to check for about a month. Debian appears to have dma off by default.

Re:I'm a bit leery.

[Otter]

Are you running with little (under 128 MB) RAM? What hardware?

If you had said that about kernels in the 2.4.1x range, I wouldn't have blinked but the newer ones don't typically have problems like that.

Re:I'm a bit leery.

[anonymous cupboard]

Um, there have been a number of improvements to the scheduler which specifically address this sort of issue. Perfect, it won't be, but it will be a lot better than the 2.4 series kernel.

What I wouls really like is for Andrew Morton's MM patches to be adopted. They bring in proper asynchronous I/O support and that will eventually dramatically help response times (however only as utilities get rewritten to adopt this). However. the improvements to X responsiveness seem to be here now.

Re:I'm a bit leery.

[devphaeton]

Since it seems your running debian and all those cpu intensive operations are also hd intensive operations have you checked hdparm -d /dev/hda . I know it is simple but it is so simple that I forgot to check for about a month. Debian appears to have dma off by default.

Yep... the base install is Debian Testing, and everything else was pulled out of "Unstable". I have enabled DMA, and it actually did make what appeared to be a slight difference.

However, other things that don't really use the hdd much (i.e. compiling programs that don't get into swap) and things will do the same.

Thanks for the suggestion anyhow :0)

Re:I'm a bit leery.

[some_god]

yes i got that too and i was wondering what the heck was going on... q3 had run so nicely before etc.. it seams like gkrellm actualy was the problem, when i shut it down i got no such problems as you describe

but it does not hapen just as often as it seasm to hapen to you and on my mandrake comp with an slightly older version of gkrellm it does not hapen at all, the comp it is hapening on is a debian testing by the way.

Re:I'm a bit leery.

[Enucite]

I agree completely. The MM patches are unbelievable. I couldn't believe the difference in responsiveness after going from 2.6.0-test5 to 2.6.0-test5-mm4!

Especially for game performance and load times, incredible difference there.

Re:I'm a bit leery.

[jelle]

do something cpu intensive, such as mkisofs, cdrecord, bzip2 some huge file, cp anything large, installing (via aptitude) or even the "Reading Package Lists...." stage of apt-get update.

That's mainly disk intensive, not CPU intensive. It may help to check the unmaskirq and dma settings of your disks. (hdparm -u 1 -d 1 /dev/hda).

Re:I'm a bit leery.

[Dacmot]

I've experienced this exact behavior before. It's because you don't have DMA enabled for your hard drive(s). "hdparm -d /dev/hda" will confirm that (off).

To fix it you need to compile the kernel with the right PCI IDE chipset support. The only way I know of checking which one it is is to compile all the PCI IDE chipset support into the kernel and catch yours by doing "dmesg | more" after rebooting with the new kernel. Find which is yours and recompile without the other ones... that should do it.

With DMA enabled you should see a very good overall speedup and no more lock-ups. Especially for hard-drive I/O stuff like "mkisofs, cdrecord, bzip2 some huge file, cp anything large, installing (via aptitude) or even the "Reading Package Lists...." stage of apt-get update"

Re:I'm a bit leery.

[anonymous cupboard]

Do you know what the word is about patch integratiuon. Although there are fixes, many of the patches are frozen out as they alter functionality on w.6. Will they end up in 2.6.1? I guess kgdb not, as Linus hates kernel debuggerers - but the aio and so on would be *really* nice.

Re:I'm a bit leery.

[Enucite]

Andrew Morten's "official" response to that question last week was:

"I haven't decided yet."

So... at the moment, no one knows what will happen. :-/

who cares?

[Anonymous Coward]

Want to get me excitied about Linux ...

1) Integrate seemless plug-in support into Mozilla.
2) Make Open Office slicker/ handle Mickeysoft documents better.
3) Make a spreadsheet that doesn't suck.
4) Make is to that I can actually cut and paste weird stuff between applications.
5) Make is so that my PC can get updated just by clicking on items and not chasing down library incompatiblites or typing "rpm --force" or "make install" or whatever.

I don't care about 1% improvement in 8 SMP mode on some kooky benchmark.

Re:who cares?

[Penguinshit]

The fix to #5 is easy.

Re:who cares?

[stratjakt]

1) Integrate seemless plug-in support into Mozilla.

Done and done! It's "seems less" useful than any other plug-in implementation I've seen. Or did you mean seamless?

Re:who cares?

[BenjyD]

Linux==kernel
Linux!=user space programs

Hence, your complaints are not about Linux, but about a bunch of programs that run on many other OSs/kernels as well as Linux.

Re:who cares?

[Curien]

I agree that those things are issues, but they have nothing to do with Linux (the kernel). This is a new release of /the kernel/. You should only get excited about it if you care what kernel you're running. Most people don't, and they shouldn't (as long as the kernel supports all their hardware).

Re:who cares?

[Lumpy]

how you got insightful I have no idea...

Everything you "want" has nothing to do with linux.

That's like asking ford to build better tires or make higher octane gas.

ASK the right people for the features you want... the people writing the software you want improvements. in...

Because you know, Microsoft Windows Stinks because I can't do live editing in Adobe Premiere, same as I wont get excited about Internet Explorer until www.theonion.com get's better graphics...

do you understand how you sound now?

Re:who cares?

[vondo]

5) Make is so that my PC can get updated just by clicking on items and not chasing down library incompatiblites or typing "rpm --force" or "make install" or whatever.

Mandrake. Almost as easy as Windows (no automatic checking mode turned on). Redhat's up2date is pretty much the same.

Re:who cares?

[stratjakt]

So long as distros like red hat are going to stick it all into a boxed product, and sell the whole thing as "linux", we can complain about those boxed apps as part of linux. Just like folks compain about mediaplayer as a windows problem.

Now, if they want to call it GheymOS (featuring the linux kernel), thats a whole different ballgame.

Re:who cares?

[GreyWolf3000]

A Debian zealot? It's been a while since I've seen your kind around here...

I was really waiting for a Gentoo zealot to pop out and say "all I have to do in Gentoo is type 'emerge update' and my whole excellent portage system is updated! Yay!"

Re:who cares?

[broeman]

you are talking about Linux-distributions, not the Linux-kernel.

1) I use gentoo, and have no problem with flash & PDFs in MozillaFirebird ... haven't given much though about integrated movies (really don't care)
2) Use ximian-oo, or better gnome-office (abiword and gnumeric are quite good for MS-documents)
3) Gnumeric
4) 3rd button?
5) I just: emerge sync & emerge -u world :) surely a apt-get could argue just as good

I don't care about 1% improvement either, but surely like the better responsiveness in X.

Re:who cares?

[/dev/trash]

1) Integrate seemless plug-in support into Mozilla.

What does Mozilla have to do with a kernel?

2) Make Open Office slicker/ handle Mickeysoft documents better.

Again what does an office app have to do with the kernel?

3) Make a spreadsheet that doesn't suck.

I'm sensing a pattern here.

4) Make is to that I can actually cut and paste weird stuff between applications.

That's a function of X not the kernel.

5) Make is so that my PC can get updated just by clicking on items and not chasing down library incompatiblites or typing "rpm --force" or "make install" or whatever.

emerge -u world. Done.

Re:who cares?

[Penguinshit]

We're slow, but we get there safely and in style!

(like a Volvo...)

Re:who cares?

[Pflipp]

1) Integrate seemless plug-in support into Mozilla.

Hey, if you wanted to say "Java", just say it. Otherwise, it's there.

2) Make Open Office slicker/ handle Mickeysoft documents better.

Constantly being worked on.

3) Make a spreadsheet that doesn't suck.

Gnumeric?

4) Make is to that I can actually cut and paste weird stuff between applications.

Ouch! ;-)

5) Make is so that my PC can get updated just by clicking on items and not chasing down library incompatiblites or typing "rpm --force" or "make install" or whatever.

Debian

Re:who cares?

[Pharmboy]

Mandrake. Almost as easy as Windows (no automatic checking mode turned on). Redhat's up2date is pretty much the same.

Right on the money. I used Mandrake on client machines and RH on servers in the pre-rhn (up2date) days. Now I use just RH, and can update, remove, install, etc. just about any package, even if I am not sitting in front of that particular box.

If the update fails, it tells me and I can do something about it. I can easily make any package where you can't update it or uninstall it unless you do so manually at the box, or not. Never had a problem using it (other than their stupid SSL debacle) in almost 2 years.

Not even Windows (the 'easiest' to use OS) will let you update a computer in Dallas while you are in Houston. Up2date will, and even let you schedule it.

Re:who cares?

[Tony]

1) Integrate seemless plug-in support into Mozilla.

Yeah!

2) Make Open Office slicker/ handle Mickeysoft documents better.

I haven't had any problems with the 1.1 series. I like it a lot better than MS-Word/MS-Excel/Powerpoint, and the import has been pretty much flawless.

3) Make a spreadsheet that doesn't suck.

There are spreadsheets that don't suck?

4) Make is to that I can actually cut and paste weird stuff between applications.

Although not universal, I've not had a problem with cutting/pasting strange things between bonobo-enabled apps.

5) Make is so that my PC can get updated just by clicking on items and not chasing down library incompatiblites or typing "rpm --force" or "make install" or whatever.

I'm running a wierd brew of Debian stable/unstable/testing/experimental, and I don't have a problem with that. Are you sure it's not an operator-headspace issue?

BTW, as other posts have mentioned, the problems you mention are not specific to Linux. 2 & 3 are perceptions, not fact; 5 is an artifact of your distribution, and 4 is fixed to a limited extent (and getting better daily).

So, only 1 is a real issue (and not much of one if you have a good distribution that installs plugins for you). 4 is definitely an issue.

Re:who cares?

[orasio]

That is not an intelligent thing to say. If RedHat sells a GNU/Linux/RedHat system, and calls it "Linux", that doens't make them the authority on the meaning of the word "linux". Linux is a kernel, and not an operating system, knowing that is _your_ duty. Nobody has the right to be ignorant.

Re:who cares?

[Linux_ho]

Linux is a kernel, and not an operating system, knowing that is _your_ duty. Nobody has the right to be ignorant.

On the contrary, everyone has the right to be ignorant. You can try to educate people, tell them Linux is just the kernel, but they don't have to listen to you. What are you going to do about it? Nothing.

Dumbass Bill of Rights:
1) Everyone has the right to be ignorant
2) Everyone has the right to get upset about other people's ignorance
3) Everyone has the right to laugh at all the people exercising the first two rights.

Re:who cares?

[orasio]

Want to get me excitied about Linux ...

No I don't.
There is someone catering to people like you, it would be RedHat, SuSE, or Mandrake, they want to get people excited in order to make a buck. That's good, but in general, developers dont care about your type. If they help you, good, if you dont like it, it's a pity.

Re:who cares?

[AstroDrabb]

Apt has been ported to RPM for a while now. It makes installing RPM's a snap. Apt for Red Hat How-To

Re:who cares?

[peter_gzowski]

Begin... rant... NOW!

How is Windows any easier than Mandrake's urpmi? First give it any rpm directory (remote or not), which is just as easy as going to downloads.com (or tucows, or wherever you get Windows software from). You can do this graphically from the Mandrake Control Centre (Add Software Location, or something like that). Then you go to Install Software, search for a package, it gives you matches with descriptions, you click the checkboxes, it figures out the dependancies, and installs them. If you just want updates, you can just use Mandrake Update, which finds the remote repositories for you. The rest of the steps are pretty much the same. Then you just sit back and let it do its thing. Try doing that with Windows update. You have to babysit it, as it will come up with boxes requiring you to hit Ok, or Next, Next, Next... or it needs a reboot, and doesn't continue the process on reboot. Sorry, I know that you are also a Mandrake fan trying to get people to realize how great it is, I just get tired of my friends saying that Linux just isn't as easy to use as Windows, then turn around and ask me to help them with one of their miriad Windows problems, which often make me think, "Well, this would be easy to solve if you were using Linux, but seeing as you're not..."

Re:who cares?

[bluesky74656]

I don't know if it's just the combination of programs I'm using, but I've never had a problem copy/pasting. Highlight text, move cursor to wherever you want it to paste to, middle click, and text is copied. In fact, whenever I have to use Windows I constantly wish I could copy/paste with only the mouse like I can in Linux.

Re:who cares?

[arkane1234]

Make is so that my PC can get updated just by clicking on items and not chasing down library incompatiblites or typing "rpm --force" or "make install" or whatever.

Note: I agreed with the rest of what you said.

Updating is made simple as HELL with Redhat 9. It doesn't get much simpler... even if you point-and-drool, it does it for you essentially.

As far as not typing anything, well.. I can't help that you're lazy, jesus. That's just how it is right now, it's a philosophy that alot of distributions go with, and the users too. Then, you have Redhat, Mandrake, Xandros, Lindows, (insert other fifteen zillion "beginner" Linux distribution's name) to choose from that mostly all have graphical updaters.

Re:who cares?

[vondo]

I'm talking about keeping Windows up to date with patches, not installing new software. Windows pops up an alert telling me I need a new patch. I click on "Review and Install" and it happens.

Your point about clicking EULAs is well taken, but I don't have to go looking for Windows patches, they come looking for me.

For this, Windows is easier. You can argue about other things and I can tell you how I can't get any real work done under windows, etc., but patching the system is still easier in Windows (assuming you don't want to go the fully automatic route with either OS).

Re:who cares?

[glenebob]

Want to get me excited about Linux?

1) Rock solid stable.
2) Open source.
3) Great networking support.
4) Solid web servers.
5) Solid SQL servers.
6) Solid remote access.
7) Lots of programming/scripting languages.

Hmmm...

Re:who cares?

[GreyWolf3000]

I myself don't use Debian, but I respect it as probably the most stable, strong distribution in the pack. I prefer Crux since it offers a highly optimized, minimalistic install (the ISO is really small), as well as a slackware-style tar.gz package system with a ports tree. Much better than Gentoo, I might add.

And yes, I am being hypocritical.

Re:who cares?

[TenPin22]

All these things are great but of no use to me. If I had all these things then I might actually get some work done so I need it to :

1) Crash Constantly
2) Closed source so it can't be fixed
3) The minimum network support required is for worm propogation.
4) Foiled ! IIS unfortunately fits your criteria.
5) The whole point of not being near your computer is not being able to work.
6) Foiled again ! VB is the best !

Now can you see why people don't want to use linux ?

Architeture

[HogGeek]

I didn't see anything in the articles to support this, but I'm assuming this is based on x86 architecture. Has 2.6 been ported to other architectures? And if so, have these AIM tests been run ?

Re:Architeture

[iq-0]

Linux is written in C, you largely overhaul the system, while not breaking support for other architectures.
So: Yes, it's ported. (or even better, it didn't need to be ported because the *really* platform specific part needn't to be changed.)

Al this said, many platforms really did get an update during the 2.5.x 2.6.0-x era. So for many platforms support has (if anything) gone up!

Re:Real world please.

[jbottero]

Apperently no body here cought the joke of the parent post. But then, it's not very funny, so...

Re:I just can't do it

[falconed]

I for one welcome our new karma distributing overlords.

Re:Real world please.

[deputydink]

Yeah, you can get AIM the benchmark tool (not the instant messager) from here

Re:Some explain to me in layman terms what the hel

[Aadain2001]

New kernel is faster and better than current ones :) And I didn't even RTFA :)

MPPE build in 2.6??

[Malc]

After all these years since I first tried to dial in to a Microsoft network I still can't do it without first compiling my own kernel and pppd! I'm just a bit annoyed as I'm sitting here watching my Debian Unstable kernel recompile. For one change: added CONFIG_PPP_MPPE=m. This is a frustrating waste of time! Will this be built in the 2.6 kernels, or do I have to hope that somebody comes up with a better implementation (in Debian non-free perhaps) for this?

Re:MPPE build in 2.6??

[htmlboy]

After all these years since I first tried to dial in to a Microsoft network I still can't do it without first compiling my own kernel and pppd! I'm just a bit annoyed as I'm sitting here watching my Debian Unstable kernel recompile. For one change: added CONFIG_PPP_MPPE=m. This is a frustrating waste of time! Will this be built in the 2.6 kernels, or do I have to hope that somebody comes up with a better implementation (in Debian non-free perhaps) for this?

how many users would benefit from having that as a default option? no, really, you're the exception here. build a kernel every few months and get on with life.

Re:MPPE build in 2.6??

[tlahoda]

Have you bothered to ask the kernel developers to do this, instead of whining about a simple kernel recompile on slashdot?

Re:MPPE build in 2.6??

[Malc]

Errr, how many users use half the things that get built by default? That's why they're built as modules.

Strewth, I am getting on with life, which is why I get annoyed having to stop and carry out pointless tasks like this. I want to update in one go without having to constantly go through this rigamorale. I don't want to have to do this on every Linux distribution I install or encounter. I don't want to have to do this whenever I create a clean install to test something quickly. Maybe you don't have more important things to do, but I do.

Re:MPPE build in 2.6??

[TenPin22]

If you don't like it, don't use it ?

Or don't change kernels often, make a script to make the upgrade quickly and without thinking, get someone else to do it or (gasp) manage your time better.

strike one off

[metroid composite]

Gnumeric (which I have on KDE at least) is a non-sucky spreadsheet. In fact, in the course I was TAing last spring the prof had to switch to it from Excel because it could handle the operations better. The only complaint I have about it is that I can't (or at least I haven't figured out) how to cut and paste into a text document (and vice versa). ...But that was point #4 as opposed to #3, so you can strike one off.

Linux sorta Scales, but the hardware doesn't...

[caveat]

I'd love to see Linux being the best OS for multiple CPU scaling.

You do need a scalable OS to suport lots of processors, of course, but you also need hardware that scales too (clustering doesn't count). Example - SGI is using Linux with NUMAflex on the Altixes to cluster 64-processor system images, but that kind of hardware isn't commodity in any way, and isn't going to be anytime soon.
Anyway, Linux doesn't scale THAT well...as of 9/2000, SGI was using IRIX for a 1024-processor single-system-image supercomputer; I've heard they can go to 2048 now, but I don't have anything to back that up. Dunno about Solaris, but I imagine it's pretty scalable as well.

Re:Linux sorta Scales, but the hardware doesn't...

[pmz]

Dunno about Solaris, but I imagine it's pretty scalable as well.

Sun advertises near-linear scaling, which seems limited mainly by how large a box Sun is willing to construct. Perhaps the UltraSPARC IV will allow 212 CPUs in the Sun Fire 15K (just don't ask me to pay the power bill for a 1696-CPU cluster!).

are really developers waiting in line?

[JVert]

Are you implying that developers are not designing for the environment untill its out of beta?

I can only think of 2 justifiable reasons for this:
1) Developers can't figure out how to install a beta or alpha kernel..
2) Developers dont trust it enough to belive that code written for a beta will work on an official release.

Re:are really developers waiting in line?

[NumLk]

Not necessarily #1, but definately #2. Its a fact of life- the code is in flux. Granted, at this late state of code development, changes to the function of the code should not be occuring, only bug fixes to previously coded functionality. That said, I'm sure it still occurs.

I know I'm throwing gasoline on a fire here, but it makes the point: Anyone that has ever tried coding something big in Java knows this firsthand. Sun changes the way Java behaves in every release, including point releases. Hopefully, Linux (and everything else) behaves better between releases, but I'm sure the code functionality still fluxes occasionally, just to show everyone who's the boss!

a better comparision would have been

[zr-rifle]

something more cpu intensive but still using network resources: SETI anyone?

anyway, I haven't had the time to crunch and digest all these wacky numbers listed in the benchmark, but when I read that "the latest stable 2.4 kernel still out-performs the 2.6.0-test development kernel on a uniprocessor server, but not on a multiprocessor server" it also means that they perform averagely equal on a multiprocessor system, or the latter outperforms the former?

Re:a better comparision would have been

[pmedwards]

That wouldn't be testing the quality of the kernel to any great extent. Multiple independent CPU bound user processes should scale close to linearly on most SMP enabled systems, even those with a "giant kernel lock".

Half rock

[roystgnr]

The "We mostly rock" statement was referring to a different benchmark (the one in the story's second link), in which the scheduler performance on single processor machines more than tripled (and performance on 8-way machines went up ~50%) between 2.5.30 and 2.6.0-test5. The first link's benchmark isn't very impressive, like you point out, but it's also not the same program.

Re:Half rock

[GooberToo]

You are correct! The scheduler reacts different to different work loads. This is why the kernel developers try hard to test their changes under a number of different workloads. To top it off with, they attempt to target the benchmarks which behave like real-world work loads rather than contrived and unrealistic workloads. That's not to say that they don't test those too, however, they clearly direct more attention at real-world workloads and corrosponding result sets.

The 2.6x series kernels will be a big step up for just about everyone that seriously uses their computer. Significant realiability improvements as well as faster thoughput on disks, much, much higher scalability for SMP (hyperthreading and numa and even highly loaded uni-systems) systems, and much lower latencies, all at the same time. Granted, there are still some tests which may not be a win-win all the way around, however, almost everything in general is an improvement with hardly any detracters.

So, saying, "we mostly rock", really is a true statement!

I see.

[Uerige]

They made the single processor version slower, so that it seems to scale alot better when adding processors. Good job.

Something's Missing

[Anonymous Coward]

Hmmm...I don't see the slashdotting benchmarks anywhere in this report.

Re:Real world please.

[tmasssey]

It's called Lotus Instant Messaging (nee Sametime). And companies are using it in the real world.

Just becaues you can't see its use outside of a toy, doesn't mean everybody can't.

Smoother scheduling in 2.6.0

[Dr. Zowie]

Devphaeton, you hit the nail on the head about 2.6.0. Its main advantage over 2.4.x (for this luser anyway) is the smoother multitasking even on a uniprocessor system. I'm running a tweaked 2.6.0-test5 on my laptop, and jobs that would make 2.4.x unusable are barely detectable (from the standpoint of moving the mouse around, typing up slashdot articles, and the like).

Of course, the ACPI support and swsusp doesn't hurt either :-)

Re:Smoother scheduling in 2.6.0

[molarmass192]

I'm anxious to move to 2.6 but I have to wait for Netlock (VPN) and Netraverse (Win98 -> Webex) to release 2.6.0 patches for their wares. I've pleaded for beta, alpha whatever patches and consistently get the "it's not production so take off" line. I'll be all over those two like stink on a dog the day 2.6.0 goes stable.

Re:Smoother scheduling in 2.6.0

[molarmass192]

Believe me, I don't use those because I want to, it's because I have too, and changing them is out of my control. The Nortel VPN piece is a hardware solution and the WebEx thing is a remote conference server.

This is going to sound ignorant but I didn't think that 2.4 could be run in UML on a 2.6 kernel. Now that I've been educated, I'm definitely going to give it a go!

Now can we get benchmarks for X?

[whitroth]

How 'bout benchmarks with new versions of X?

I keep hoping for faster and smaller....

mark "silly me"

Yup, sadly

[petermdodge]

Yeah, look at all the new intellectual property they can claim there!

Seriously, they'll have a field day prosecuting people on any version of Linux, 2.4 or 2.6. It seems the entire goal of the SCO lawsuit is to defame Linux. The companies on the recieving end should get an injunction to silence SCO until the thing gets resolved.

In the end, the only entity that clearly benefits from all this is Microsoft, cause it's just weakining faith in Linux.

Re:Yup, sadly

[glynor]

In the end, the only entity that clearly benefits from all this is Microsoft, cause it's just weakining faith in Linux.

Actually, as I had pointed out in a previous comment, and as is blatantly illustrated here, there are two "entities" that benefit from SCO's claims. Microsoft being one, and SCO (and their stock-laden executives) being the other.

Be sure to note where that second link came from.

Single-processors

[petermdodge]

The benchmark pretty much proves that some change is needed for it to cater to the standard user, as the standard home Linux user, myself included, only have one processer in their computer.

SCO Kernels

[Schwartzboy]

No, no, no! They don't have to "make up" a shred of evidence, you insensitive clod! Bear with me as I walk you through the intensive fact-finding process that will prove beyond a shadow of a doubt that 2.6 does, in fact, have more proprietary SCO stuff in it than any *nix ever has before! Watch as the scene unfolds...

DARL: So, um, hey. It looks like there's this new "too-pointe-six colonel" out on the market from those Lenn-ucks people. We own all that too, right?

SUIT: Well, sir, it's like this. Do you remember how the 2.4 kernel had all of those lines of code in them that are ours, even though they showed up in textbooks before most of our stuff existed?

DARL: Sure, but how does that help us with this new thing?

SUIT: Think about it. Most operating systems, according to my extensive research during years of never having looked at a computer before, contain the same code that they always did, plus a couple of lines of new comments and an extra variable or two that shows how much you're able to charge users for the new features. Just think about the Windows 95 and 98 thing. Perfect example there.

DARL: But...my mansion only has 93 windows. Where is this heading?

SUIT: *blinks* Errr...yeah. Well, it's all the same code, and even those sneaky Linux commies try to pull a fast one on us and put one of those different codes in there, we can always assert our ownership of these "opened sources" files that I just printed out. I asked this guy, you know, and he said that all of these sources are what's in Linux, and since I printed it on paper and stuff, I figure it must be a textbook. Since we own all the words that show up in textbooks, and this has a lot of words, I think we've found ourselves a new angle here.

DARL: Smithers, cry havoc and let slip the Lenn-ucks colonel lawsuit monkeys once more!

I do so hate having to correct you people. *sigh*

Am I missing something here?

[AntiGenX]

If you look at the difference between the outcomes for uniprocessor vs dual. There doesn't seem to be very good scaling.

linux-2.6.0-test5 - 992.06 - Uni
linux-2.6.0-test5 - 1017.43 - Dual
linux-2.6.0-test5 - 5406.68 - Quad

Does this mean that you only gain 3.49% when adding a 2nd processor? Obviously I don't expect things to scale linear but 3%!? Am I missing something here? And then 81.65% for quad? I'm not trolling, I'm looking for someone to explain what I'm missing.

Re:Am I missing something here?

[gyrovague]

You can't directly compare the results between platforms. Each platform runs to a max, so the amount of work is not proportional. The amount of disk IO is also increased for the larger systems. You could use reaim to do such a comparison, but that's not what we did.

Re:Am I missing something here?

[rakarnik]

Yes, the number for dual is not 1017, but more like 1545.

Here are the actual numbers for 2.6.0-test5 and the compute workload:
1 - 992.06 - 100%
2 - 1545.03 - 155%
4 - 5175.28 - 521%

Now for why the 4 processor case is actually 5 times better than the single CPU case, I do not know enough about the benchmarks to comment.

Re:Am I missing something here?

[GooberToo]

Not all workloads have to scale linearly. It also depends on how the benchmark was configured. Remember, there are many factors which effect scalability, not to mention many subsystems. I don't recall off the top of my head exactly what the benchmark was trying to measure. For example, it could of been trying to measure scalability with high memory contention, or any number of odd cases. In other words, unless the test was specificaly trying to measure CPU scalability, you shouldn't be attempting to place such emphesis on it.

Just FYI, I read this story some time ago on Kernel Trap and I'm too lazy to go look at it again to further offer up details.

Re:Am I missing something here?

[rakarnik]

Oops, pot kettle black. The UP number should be more like 1017, but the point still stands.

Re:Am I missing something here?

[mvdw]

Of course, you are assuming that all the machines are identical; ie, the four-processor machine has 4 CPUs identical to the single processor machine. This may not be the case. I'd assume the numbers are only really meaningful as comparisons between kernel versions within a single machine class.

Re:I just can't do it

[llamalicious]

Dude, if you're REALLY karma whoring, its not super-fantastic, its SUPERTASTIC!

And MSFT is not teh ghey, they are the minions of hell.

SCO sucks.

Jesus help me, I'm trolling slashdot!

OT: Re:GREAT

[proj_2501]

Oh, just like how the No Child Left Behind Act cuts the funding of schools who need more! EXCELLENT!

Updated VM code in 2.4.23-pre*

[Spoke]

The latest 2.4.23-pre* has had substantial amount VM updates from Andrea Arcangeli's branch integrated.

You should give that a shot as it has been reported to substantially improve kernel behavior when under VM pressure like when you're doing intensive IO as described in your post.

BTW, out of the tasks you listed most of them are IO bound, not CPU bound. Notable exceptions are bzip2 unless you have a REALLY fast CPU.

The kernel isn't everything

[skamp]

I've tried the new kernel, and I got more responsiveness issues than improvements. But besides that (I might very well have misconfigured something), I'd like to point out that the kernel itself isn't all that matters: the new drivers that accompany it are just as much important. I noticed a significant increase in X's launch time as well as a whopping 250 FPS with glxgears to be compared to the 150 FPS I got with my 2.4.22 setup. This is probably due to major improvements that were brought to the drivers for my i830M chipset.

Re:Real world please.

[gyrovague]

Sorry, these workloads have nothing to do with instant messaging. They are simulations of real-world database systems. The AIM company not longer exists, but the name lives on.

Re:Some explain to me in layman terms what the hel

[gyrovague]

This is a simulation of a database load. Basically, larger numbers are better. The numbers are tasks per minute and peak user count. The load adds users each iteration until a max is reached. See http://developer.osdl.org/cliffw/reaim/index.html for more

Scaling, et al

[Anonymous Coward]

First, we need the common elements of bproc/mosix in the kernel. The specialized stuff, for each approach, may need to be kept out, but some level of generic process migration support is important.

Second, unicasting looks to be slower. Ugh. I don't like that. That suggests to me that there are segments of code which are optimized for multi-processor use - which is great - but either there aren't uniprocessor versions, or the uniprocessor versions are highly non-optimal.

Third, scaling needs to be improved. I don't know if Linux staggers bus use, to optimize usage, but if it doesn't, it should. Perhaps make use of the existing QoS code, or inject wait states if you know an internal bus is going to be heavily loaded.

Fourth, the scaling between 2-CPU and 4-CPU suggests that something is kicking in at the 4-CPU level that's seriously good. My guess would be NUMA, which IIRC, was tied to the 4+ CPU level. NUMA developers might want to look and see if there's anything which stipulates more CPUs than it actually requires.

Fifth, we need to sort out this damn RTOS issue. Linux 2.6 is supposed to go RT when the priority reaches a certain level, but it seems to be more of an rtsched-type scheduler trick than actual RT code. There are lots of approaches out there (RTAI springs to mind) and it might be good if someone added some good hooks into the OS for real-time operation.

Sixth, and this goes along with the above, HP have a scheduler plugin system. Ok, it seems that pluggable schedulers aren't in vogue, but I do like the concept of a scheduling tree with tunable branches.

Seventh, either use UGASI or don't. Adding in IPSEC is cool, and all that, but the old IPv6 stack is beginning to get stale. (In fact, there's also a lot in the IPv4 stack that's stale, and needs to be replaced.)

Last, we've got the filesystems. I've not seen much serious CODA or Intermezzo work, recently, and I've never known the kernel-provided Intermezzo to work without problems. On the other hand, we've got Lustre, which seems to be a whole lot faster, and seems to be under active development. Yes, it's "late in the day" to go adding whole new components, but the impact would be minimal, and it would make a lot of networked users very happy.

(And happy network users give karma to slashdot freaks! :)

Re:lousy presentation of data

[gyrovague]

The graphs are available with the full test report. I don't post graphs to mailing lists, not much point. see http://developer.osdl.org/cliffw/reaim/index.html follow the links to a specific test, and you'll find plenty-o-graphs.

Re:Good Question, Bad Arithmetic

[stef49]

a quad cpu more performant than 4 * single cpu?
Odd but not impossible.

For example, if in the single cpu config the processes are doing a lot of memory-cache missed then having 4 cpus (with 4 times more the amount cache) could reduce the number a cache misses and so could make the quad configuration more than 4 times faster.

The same reason could explain why 2 cpus are not faster than one: if 2 caches are not large enough and if the processes have a very bad locality then you may get as much cache misses with the dual cpu system than with the single cpu system.

Re: Debian Zealot

[Linus Sixpack]

Why knows if Debian lurks in the hearts of men.... The Penguin knows! Debian redefined Linux for me.

Re:Real world please.

[tomhudson]

Ok, the reason I posted that it wasn't an IM client was because

1. some people might be misled into thinking that /.ers are so braindead as to try to do kernel benchmarking using an IM client
2. I looked at the post, debated as to whether to moderate it (but we don't have a -1 - lame attempt at humour mod)
3. it just wasn't funny (I make jokes all the time, and some (maybe a lot of them) end up not being funny, either. Or the point is missed. Or the reader doesn't get the ref. to spaceballs/SCO/whatever. such is the risk of humour).

Re:Good Question, Bad Arithmetic

[AntiGenX]

Yeah, sorry I'm on major meds following the removal of my wisdom teeth!

It may seem like i was on crack, but I promise they were prescription meds.

Re:Real world please.

[rsmith]

AIM (now at version 7) is not an instant messanger client. It's a benchmarking tool.

Hmm, you wouldn't want to be on the receiving end of the AIM-7 benchmark.

It packs quite a punch

Why is this modded flamebait?

[scosol]

I'm osrry, but he's right.

Linux's SMP support is in its infancy- Solaris, HPUX, AIX etc have been hammering it for YEARS.

You can't just expect Linux to instantly be equal to those OSes in that regard.
(INsert obligatory "without illegal insertion os SCO-owned SMP code in to Linux by IBM blah blah blah :p )

Nice idea, failed execution.....

[TrancePhreak]

How about some charts/graphs... Reading raw numbers in long strains is rather dull. It's easy to get them mixed up as well.

Are they trying to hide something this way? ;)

You want charts?

[gyrovague]

I don't post charts when sending to a text-only mailing list such as linux-kernel. Not much point to that. If you'd like charts, see the full reports here: http://developer.osdl.org/cliffw/reaim/index.html

Re:You want charts?

[TrancePhreak]

Ug, that's a little better, but still a little mean on the eyes.

Is it even smart to think of that?

[Inoshiro]

Single proccessor systems are the most common, and always will be. There are millions of millions of them out there.

Dual proc and quad proc systems are also semi-common, but usually only in server scenarios. The best ratio you'll ever see on them is probably around 50 to 1 -- 1 quad CPU server, 50 uni CPU clients.

Each time you move up, you get diminished returns. At what point do you go, "hey, making Linux scale more is causing a detriment to our single-CPU millions, and we're spending man years going from 512 CPUs to 1024 CPUs -- is it worth it?"

I'm sure Irix is great for 1024 CPU installs, because SGI sells the hardware and has no problem charging an arm and a leg for the software needed to run it. After all, if you're on the market for a 1024 CPU nuclear fission simulation computer, you can't really go and grab just anything off the shelf to do it on.

The Linux community won't gain anything if we go to the point where 16 or more CPUs is something the kernel can do easily. How many of us own these systems? How many of us can develop and bugtest on these systems? How complex will the kernel locking on all the subsystems become in that setup? When is Linux scaled too much?

Re:Is it even smart to think of that?

[buttahead]

Single proccessor systems are the most common, and always will be.

Come back here in ten years... we'll see if you have foot in mouth disease. I suspect you do.

Re:Is it even smart to think of that?

[sgtrock]

Oh, I don't know. There are a lot of us who work for companies that own IBM mainframes, for example. They haven't disappeared off the face of the earth despite all the doomsayers for the past 3 decades.

I think there are some jobs that are best performed by very large boxes. If a company like Irix or IBM wants to fund the developers or donate some of their codebase, why should the Linux kernel developers turn it down?

After all, IBM was responsible for a lot of the donations to the 2.6 kernel that theoretically should make 64 processor boxes quite feasible. We won't know until some actual production boxes come online, but all reports of the 2.6 test kernels has been pretty positive.

I'm sure IBM did so in the full expectation that they would be able to sell enough 64 CPU linux boxes to recoup their investment. If they thought that they could sell 1024 CPU boxes, I'm sure they'd figure out a way to donate that code, too.

Fine grained multitasking and performance

[Shulai]

How does affects the increasing of clock speed, in order to get a smoother multitasking, specially in older machines?

Currently, the clock ticks at 1KHz, vs the older 100Hz frequency... This means, a lot more time spent in context switching... As the clock freq is independent of CPU speed, is has greater impact in such cases.

I still have to work with 3+ y.o. computers (My own is 5 y.o). How much gross degradation that means?

Re:Real world please.

[tomhudson]

But then you miss the ones that are genuinely funny (rare, but worth it. sort of like browsing at -1 when you moderate)