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.
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).
I remember using a 386 20MHz running X and Netscape and lots of stuff back in 1995, when I worked for the student union. It wasn't fast but we could work on it. Eventually, we whined about it and got a new box.
Employee of Inrupt, Project Release Manager and Community Manager for Solid
Nope, you're right, but autopackage can figure out what libraries are present and retrieve (assuming they've been packaged) the libraries from a DNS style distributed network, apt style.
My aim was a little different from yours though. I was going for complete binary packaging from beginning to end. No source building, as automated ./configure; make; make install;s tend to make distro specific code.
Hmmm, how did you get the impression that autopackage is source based? A .package is a binary package from end to end, the user doesn't need to compile anything.
All I provided was an archive format and a self extracting gui or command line installer that totaled under 50k of overhead
We're using a similar idea except the scripting language and front end code is external and installed-on-demand when you run a .package file if it's not already present to minimize package file bloat.
Maybe I should start it back up. It's not like I have much else going on lately. hmm...
If you're interested in the problem, please take a close look at autopackage first, feel free to hop onto IRC (freenode#autopackage) and talk to us first. We're normally around in the evenings GMT (both the core developers are in europe). It'd be a shame to duplicate effort when our projects sound so similar.
I know Mandrake has done this for a while. I think RedHat does the same. I can't remember with Gentoo, but I did try some hdparm flags and didn't notice any real change.
/dev/hd[x]' and look at the output. It will tell you which modes are in use for the current drive. Then do 'hdparm /dev/hd[x] -t' and see how fast your drive is running. Look at different optimize flags and test after each to find the best settings.
/dev/md[x]) seperately, but test the array as a whole.
Basicly, do 'hdparm
You can even use it to test cdroms and RAID arrays. Just remember that when you optimize an array, you want to optimize each disk (/dev/hd[x], not
One other note, the '-t' flag, like most synthetic tests, may not show the best settings for the drive. A lot of times a timed kernel compile (or my new fav test, a mozilla 1.0 compile) will reveal benifits, or detraction, not shown in a synthetic benchmark.
I'd rather you do it wrong, than for me to have to do it at all.
Maybe you should try
nice -n 19 make && nice -n 19 make install
No responsive problems AND your computer uses all those spare cycles while you are doing other things.
I do this all the time and desktop responsiveness doesn't bog down at all. Kernel doesn't take much longer to compile either.
Toddlers are the stormtroopers of the Lord of Entropy.
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.
yes!
It sucks, but that is your fault. no, hear me out, this isn't one of those "so fix it" rants:
I've been building my own kernel since 1.2.13 days. I've [until recently] never built a crap kernel (sometimes left things out I wanted in, like sound, but it always worked smoothly, even under load).
I recently tried to roll my own 2.4.{7,18} kernels under RH 7.2, and it did exactly what you describe. The slightest bit of IO concurrent with load would stutter up the entire system.
However, redhat's kernels (based on the same version) would NOT have this problem. Smooth as astroglide on a banana peel.
So the conclusion is that the kernel broke sometime during the 2.4 task-switcher/vm mapper debacle, but not in a "no longer works" sense, but rather in that deep wizardry is neeeded to build a "good" kernel. Obviously you and I forgot to check the "do not fuck up" box.(*)
I would totally go for *BSD, but a clean RH install works ok, and I judge the overhead of applying updates to keep the system secure less than a complete OS shift and learning to administer a new not-quite-the-same system.
(*)The first instance of the "do not fuck up" box was found on the LaserWriter driver for System 7.x: if you unchecked download fonts, then _nothing_ would come out, otherwise it worked like a charm. Likewise, acrobat reader has an "avoid Level-1 PS like the plague" option that allows you to print what appears on screen even when it contains greek letters.
The problem is that each configuration dialog has this box hidden as something else, but it is always there, somewhere.
What often helps a lot, is adding a -u1 (unmask irq). From the man page:
"A setting of 1 permits the driver to unmask other interrupts during processing of a disk interrupt, which greatly improves Linux's responsiveness"
I have a 486 (75 MHz, I think) laptop, with 12 MB RAM. It runs Debian Woody with X11 and the Blackbox window manager. I was using it yesterday to read slashdot and debianplanet. I was using the Dillo browser. Performance was slow, but tolerable. If I want to use emacs, I kill X, or else it starts swapping.
The real holdup for speed is the lack of RAM, rather than the anemic processor, but as long as I'm careful about how many processes I have going, it's fast enough. The holdup for usability is the small, 640x480 screen, and that's more a matter of it being an old laptop than being old.
It's interesting to notice that this little box could run Win3.1, but isn't a speed demon with that either. Win3.1, of course, is old and single-tasking and insecure and nothing modern runs on it. Putting a modern, proprietary OS on this sort of old hardware is probably out of the question.
Based on this, I think that any Pentium with a lot of RAM (more than 64 MB) would be just peachy for email/websurfing. Any Pentium with >32MB should be useable, if set up sensibly.
See what I've been reading.