Posted by
michael
on from the make-kpkg-kernel_image dept.
Sivar writes "Andrew Morton of EXT3 fame has posted benchmarks of Linux 2.5.47 prerelease compared with the latest from the current 2.4 series. With some tasks more than tripling in performance, the future looks very promising."
I'm really sorry.
by
FreeLinux
·
· Score: 5, Informative
Try it again.
In a reply on lkml to Aaron Lehmann's praising of the contest results of the latest 2.5-mm kernel Andrew Morton [interview] explains some of the important performance and design differences between the 2.4 stable series and the 2.5 development series accompanied by illustrating benchmarks.
Most significant gains can be expected at the high end such as large machines, large numbers of threads, large disks, large amounts of memory etc. [...] For the uniprocessors and small servers, there will be significant gains in some corner cases. And some losses. [...] Generally, 2.6 should be "nicer to use" on the desktop. But not appreciably faster.
From: Aaron Lehmann To: linux-kernel Subject: Re: [BENCHMARK] 2.5.47{-mm1} with contest Date: Mon Nov 11 2002 - 18:04:53 AKST
On Tue, Nov 12, 2002 at 10:31:38AM +1100, Con Kolivas wrote: > Here are the latest contest (http://contest.kolivas.net) benchmarks up to and > including 2.5.47.
This is just great to see. Most previous contest runs made me cringe when I saw how -mm and recent 2.5 kernels were faring, but it looks like Andrew has done something right in 2.5.47-mm1. I hope the appropriate get merged so that 2.6.0 has stunning performance across the board.
From: Andrew Morton To: linux-kernel mailing list Subject: Re: [BENCHMARK] 2.5.47{-mm1} with contest Date: Tue Nov 12 2002 - 02:04:23 AKST Aaron Lehmann wrote: > > On Tue, Nov 12, 2002 at 10:31:38AM +1100, Con Kolivas wrote: > > Here are the latest contest (http://contest.kolivas.net) benchmarks up to and > > including 2.5.47. > > This is just great to see. Most previous contest runs made me cringe > when I saw how -mm and recent 2.5 kernels were faring, but it looks > like Andrew has done something right in 2.5.47-mm1. I hope the appropriate get merged so that 2.6.0 has stunning performance across > the board.
Tuning of 2.5 has really hardly started. In some ways, it should be tested against 2.3.99 (well, not really, but...)
It will never be stunningly better than 2.4 for normal workloads on normal machines, because 2.4 just ain't that bad.
What is being addressed in 2.5 is the areas where 2.4 fell down: large machines, large numbers of threads, large disks, large amounts of memory, etc. There have been really big gains in that area.
For the uniprocessors and small servers, there will be significant gains in some corner cases. And some losses. Quite a lot of work has gone into "fairness" issues: allowing tasks to make equal progress when the machine is under load. Not stalling tasks for unreasonable amounts of time, etc. Simple operations such as copying a forest of files from one part of the disk to another have taken a bit of a hit from this. (But copying them to another disk got better).
Generally, 2.6 should be "nicer to use" on the desktop. But not appreciably faster. Significantly slower when there are several processes causing a lot of swapout. That is one area where fairness really hurts throughput. The old `make -j30 bzImage' with mem=128M takes 1.5x as long with 2.5. Because everyone makes equal progress.
Most of the VM gains involve situations where there are large amounts of dirty data in the machine. This has always been a big problem for Linux, and I think we've largely got it under control now. There are still a few issues in the page reclaim code wrt this, but they're fairly obscure (I'm the only person who has noticed them;))
There are some things which people simply have not yet noticed.
Andrea's kernel is the fastest which 2.4 has to offer; let's tickle its weak spots:
Run mke2fs against six disks at the same time, mem=1G:
2.4.20-rc1aa1: 0.04s user 13.16s system 51% cpu 25.782 total 0.05s user 31.53s system 63% cpu 49.542 total 0.05s user 29.04s system 58% cpu 49.544 total 0.05s user 31.07s system 62% cpu 50.017 total 0.06s user 29.80s system 58% cpu 50.983 total 0.06s user 23.30s system 43% cpu 53.214 total
2.5.47-mm2: 0.04s user 2.94s system 48% cpu 6.168 total 0.04s user 2.89s system 39% cpu 7.473 total 0.05s user 3.00s system 37% cpu 8.152 total 0.06s user 4.33s system 43% cpu 9.992 total 0.06s user 4.35s system 42% cpu 10.484 total 0.04s user 4.32s system 32% cpu 13.415 total
Write six 4G files to six disks in parallel, mem=1G:
2.4.20-rc1aa1: 0.01s user 63.17s system 7% cpu 13:53.26 total 0.05s user 63.43s system 7% cpu 14:07.17 total 0.03s user 65.94s system 7% cpu 14:36.25 total 0.01s user 66.29s system 7% cpu 14:38.01 total 0.08s user 63.79s system 7% cpu 14:45.09 total 0.09s user 65.22s system 7% cpu 14:46.95 total
2.5.47-mm2: 0.03s user 53.95s system 39% cpu 2:18.27 total 0.03s user 58.11s system 30% cpu 3:08.23 total 0.02s user 57.43s system 30% cpu 3:08.47 total 0.03s user 54.73s system 23% cpu 3:52.43 total 0.03s user 54.72s system 23% cpu 3:53.22 total 0.03s user 46.14s system 14% cpu 5:29.71 total
Compile a kernel while running `while true;do;./dbench 32;done' against the same disk. mem=128m:
2.5.46: Throughput 19.3907 MB/sec (NB=24.2383 MB/sec 193.907 MBit/sec) Throughput 16.6765 MB/sec (NB=20.8456 MB/sec 166.765 MBit/sec) make -j4 bzImage 412.16s user 36.92s system 83% cpu 8:55.74 total
2.5.47-mm2: Throughput 15.0539 MB/sec (NB=18.8174 MB/sec 150.539 MBit/sec) Throughput 21.6388 MB/sec (NB=27.0485 MB/sec 216.388 MBit/sec) make -j4 bzImage 413.88s user 35.90s system 94% cpu 7:56.68 total - fifo_batch strikes again
It's the "doing multiple things at the same time" which gets better; the straightline throughput of "one thing at a time" won't change much at all.
Corner cases....
Performance gains mostly for high-end
by
Dacmot
·
· Score: 5, Interesting
I'm a huge linux fan and I love to brag about how much better than Windows it is, etc. However I don't think it's right to say false truth like "linux 2.6 will be 3 times faster!!!!!" KernelTrap mentions that:
Most significant gains can be expected at the high end such as large machines, large numbers of threads, large disks, large amounts of memory etc. [...] For the uniprocessors and small servers, there will be significant gains in some corner cases. And some losses. [...] Generally, 2.6 should be "nicer to use" on the desktop. But not appreciably faster.
Some of the biggest improvements for desktop responsiveness can be found (for Kernel 2.4.x) at Con Kolivas' web site of performance linux patches.
--
Re:Make it simple please
by
jericho4.0
·
· Score: 5, Informative
It'll be quite a while before recompiling a kernel gets any simpler. Recompiling assumes that you know (somewhat) what you're doing. Keep at it. It took me at least 10 tries before I compiled a bootable kernel.
quick hint; isnstall the kernel sources that came with your dist. Use the.config file found in this to compile first. These are the settings that your kernel was compiled with. The you can use make xconfig alter a known working config. Good luck.
-- "A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
Re:This is This is the exact opposite of my findin
by
be-fan
·
· Score: 5, Informative
Um, doing benchmarks between an Athlon XP and a Pentium 4 is folly. The P4 has notoriously slow context switching performance. Also, if you are running a small number of threads, your computer isn't spending a whole lot of time thread switching anyway, so the hit doesn't really affect you. When you have lots of threads, scheduling becomes far more important, and so the increase is much more noticible.
-- A deep unwavering belief is a sure sign you're missing something...
Re:So what does this mean for the everyday linux u
by
iabervon
·
· Score: 5, Informative
You'll get better interactive performance under load. So if you're encoding an mp3 and writing your home directory to a CD, your mouse cursor won't stick and your windows will refresh reasonably well. Unless you're doing something kind of disk/processor intensive, you won't notice the difference, because 2.4 is too good already for there to be much improvement. If you try to encode 32 mp3s at the same time, 2.6 will actually do worse than 2.4, but at least it won't make ls quite so slow.
The main goals are interactivity (input gets handled quickly), low latency (your mp3 player gets a chance to send the next second of audio to the sound card before this second is over), and fairness (every program makes at least a little progress after a short amount of time).
Re:So what does this mean for the everyday linux u
by
Azar
·
· Score: 5, Informative
Overall throughput has not increased (actually, it is believed to have decreased). So the overall speed of the system is relatively equal to the 2.4 series of kernels. You probably won't see any major performance speedups in any apps you use.
However, the overall responsiveness of the system is improved. Most people who have used it have claimed that it feltmuch faster than the 2.4 series. You won't have starved processess.
This means if you're running XMMS and you compile a kernel, XMMS won't just hang until the compilation is done. The kernel developers have done a great job in improving -fairness- between processes.
Mostly, the results will be seen on Big Iron and server applications, but the overall desktop experience is expected to improve.
Re:Make it simple please
by
Wavicle
·
· Score: 5, Interesting
It is simple, tar -xvzf linux-{current}.tar.gz. cd linux; make menuconfig; make dep bzImage modules modules_install
You're joking, right? How many options in 2.5.47 must be selected in order for your run of the mill $9 generic PS/2 keyboard to work? I can't tell you how much fun it was building 2.5.47, missing one *somewhere* and suddenly I couldn't do anything because my keyboard stopped working.
The kernel only has an expert mode. It would be nice if there were a higher order config that asked you basic questions and built the things you were most likely to need, with the option of going into a more expert mode if you needed to fine tune something.
-- Education is a better safeguard of liberty than a standing army. Edward Everett (1794 - 1865)
Wow, you can disprove Ahmdahl's law?
by
Fefe
·
· Score: 5, Informative
Please write and publish a paper about it!
This is a major breakthrough in computer science.
It also is quite unlikely, since Ahmdahl's law is a trivial observation that is completely independent of parallelization or even software engineering (it also applies to hardware design or even accounting). Basically, it says: if initially only 10% of X (CPU cycles, money, whatever you are trying to save) is spent in the part you are optimizing, there is an upper bound of 10% to the X you can save.
I'm very interested in how you can disprove that.
Re:Linux Benchmarks
by
Anonymous Coward
·
· Score: 5, Funny
I don't know about troll, but perhaps just an overactive imagination:)
Apparently he works for a development firm, studies meterology, works for Verizon store at a local mall, owns a chain of pet stores in London, and has a thing for CmdrTaco.
Read together, they make amusing reading:)
Disk buffers & memory subsystem updated??
by
Anonymous Coward
·
· Score: 5, Interesting
I'm a big time VMware user (I use it for testing and Windows). I usually have 2 or 3 VMware machines running at any given time and I have plently of memory (usually 1GB, sometimes more). However, the disk buffer (or disk caching) of Linux sucks ass. I'm not kidding, if I have 1GB of memory, 900+ megs will be used for disk buffers and my very important interactive VMware processes will be swapped out to the slow disk swap file. Just using one of the VMware processes causes a lot of disk I/O and all that I/O gets loaded into the disk buffers in memory then when I go to use another VMware process it has to come out of swap. Linux is pretty bad about this with normal processes, but VMware exasperates the problem.
To boil it down: The disk buffering in 2.4 is way , way too aggressive and I haven't figured out a way to fix it. I need to be able to either limit the total ammount of memory the buffers will use or a better method would be to tag certain processes so that they will never be moved into swap for disk buffers (moving to swap "normally" is OK, just not for disk buffers). Or maybe just make it never swap out any process for disk buffers.
It seems Windows uses a more reasonable disk buffering technique and VMware works better there (especially when using several instances). I don't want to use Windows as my primary OS though because I like the built-in disk encryption and network security of Linux (the ip filter stuff is much better than Windows).
Anyone know if 2.5 has got any better disk buffering?
Slashdot Mirror
With some tasks more than tripling in performance, the future looks very promising
:-(
Damn, I wish my video card had kernel updates
In college, really poor, need a flatscreen.
Will it make the internet faster?
Try it again.
;))
In a reply on lkml to Aaron Lehmann's praising of the contest results of the latest 2.5-mm kernel Andrew Morton [interview] explains some of the important performance and design differences between the 2.4 stable series and the 2.5 development series accompanied by illustrating benchmarks.
Most significant gains can be expected at the high end such as large machines, large numbers of threads, large disks, large amounts of memory etc. [...] For the uniprocessors and small servers, there will be significant gains in some corner cases. And some losses. [...] Generally, 2.6 should be "nicer to use" on the desktop. But not appreciably faster.
From: Aaron Lehmann
To: linux-kernel
Subject: Re: [BENCHMARK] 2.5.47{-mm1} with contest
Date: Mon Nov 11 2002 - 18:04:53 AKST
On Tue, Nov 12, 2002 at 10:31:38AM +1100, Con Kolivas wrote:
> Here are the latest contest (http://contest.kolivas.net) benchmarks up to and
> including 2.5.47.
This is just great to see. Most previous contest runs made me cringe when I saw how -mm and recent 2.5 kernels were faring, but it looks like Andrew has done something right in 2.5.47-mm1. I hope the appropriate get merged so that 2.6.0 has stunning performance across the board.
From: Andrew Morton
To: linux-kernel mailing list
Subject: Re: [BENCHMARK] 2.5.47{-mm1} with contest
Date: Tue Nov 12 2002 - 02:04:23 AKST
Aaron Lehmann wrote:
>
> On Tue, Nov 12, 2002 at 10:31:38AM +1100, Con Kolivas wrote:
> > Here are the latest contest (http://contest.kolivas.net) benchmarks up to and
> > including 2.5.47.
>
> This is just great to see. Most previous contest runs made me cringe
> when I saw how -mm and recent 2.5 kernels were faring, but it looks
> like Andrew has done something right in 2.5.47-mm1. I hope the appropriate get merged so that 2.6.0 has stunning performance across
> the board.
Tuning of 2.5 has really hardly started. In some ways, it should be tested against 2.3.99 (well, not really, but...)
It will never be stunningly better than 2.4 for normal workloads on
normal machines, because 2.4 just ain't that bad.
What is being addressed in 2.5 is the areas where 2.4 fell down: large machines, large numbers of threads, large disks, large amounts
of memory, etc. There have been really big gains in that area.
For the uniprocessors and small servers, there will be significant gains in some corner cases. And some losses. Quite a lot of work has gone into "fairness" issues: allowing tasks to make equal progress when the machine is under load. Not stalling tasks for unreasonable
amounts of time, etc. Simple operations such as copying a forest of files from one part of the disk to another have taken a bit of a hit from this. (But copying them to another disk got better).
Generally, 2.6 should be "nicer to use" on the desktop. But not appreciably faster. Significantly slower when there are several processes causing a lot of swapout. That is one area where fairness really hurts throughput. The old `make -j30 bzImage' with mem=128M takes 1.5x as long with 2.5. Because everyone makes equal progress.
Most of the VM gains involve situations where there are large amounts of dirty data in the machine. This has always been a big problem
for Linux, and I think we've largely got it under control now. There are still a few issues in the page reclaim code wrt this, but they're
fairly obscure (I'm the only person who has noticed them
There are some things which people simply have not yet noticed.
Andrea's kernel is the fastest which 2.4 has to offer; let's tickle its weak spots:
Run mke2fs against six disks at the same time, mem=1G:
2.4.20-rc1aa1:
0.04s user 13.16s system 51% cpu 25.782 total
0.05s user 31.53s system 63% cpu 49.542 total
0.05s user 29.04s system 58% cpu 49.544 total
0.05s user 31.07s system 62% cpu 50.017 total
0.06s user 29.80s system 58% cpu 50.983 total
0.06s user 23.30s system 43% cpu 53.214 total
2.5.47-mm2:
0.04s user 2.94s system 48% cpu 6.168 total
0.04s user 2.89s system 39% cpu 7.473 total
0.05s user 3.00s system 37% cpu 8.152 total
0.06s user 4.33s system 43% cpu 9.992 total
0.06s user 4.35s system 42% cpu 10.484 total
0.04s user 4.32s system 32% cpu 13.415 total
Write six 4G files to six disks in parallel, mem=1G:
2.4.20-rc1aa1:
0.01s user 63.17s system 7% cpu 13:53.26 total
0.05s user 63.43s system 7% cpu 14:07.17 total
0.03s user 65.94s system 7% cpu 14:36.25 total
0.01s user 66.29s system 7% cpu 14:38.01 total
0.08s user 63.79s system 7% cpu 14:45.09 total
0.09s user 65.22s system 7% cpu 14:46.95 total
2.5.47-mm2:
0.03s user 53.95s system 39% cpu 2:18.27 total
0.03s user 58.11s system 30% cpu 3:08.23 total
0.02s user 57.43s system 30% cpu 3:08.47 total
0.03s user 54.73s system 23% cpu 3:52.43 total
0.03s user 54.72s system 23% cpu 3:53.22 total
0.03s user 46.14s system 14% cpu 5:29.71 total
Compile a kernel while running `while true;do;./dbench 32;done' against
the same disk. mem=128m:
2.4.20-rc1aa1:
Throughput 17.7491 MB/sec (NB=22.1863 MB/sec 177.491 MBit/sec)
Throughput 16.6311 MB/sec (NB=20.7888 MB/sec 166.311 MBit/sec)
Throughput 17.0409 MB/sec (NB=21.3012 MB/sec 170.409 MBit/sec)
Throughput 17.4876 MB/sec (NB=21.8595 MB/sec 174.876 MBit/sec)
Throughput 15.3017 MB/sec (NB=19.1271 MB/sec 153.017 MBit/sec)
Throughput 18.0726 MB/sec (NB=22.5907 MB/sec 180.726 MBit/sec)
Throughput 18.2769 MB/sec (NB=22.8461 MB/sec 182.769 MBit/sec)
Throughput 19.152 MB/sec (NB=23.94 MB/sec 191.52 MBit/sec)
Throughput 14.2632 MB/sec (NB=17.8291 MB/sec 142.632 MBit/sec)
Throughput 20.5007 MB/sec (NB=25.6258 MB/sec 205.007 MBit/sec)
Throughput 24.9471 MB/sec (NB=31.1838 MB/sec 249.471 MBit/sec)
Throughput 20.36 MB/sec (NB=25.45 MB/sec 203.6 MBit/sec)
make -j4 bzImage 412.28s user 36.90s system 15% cpu 47:11.14 total
2.5.46:
Throughput 19.3907 MB/sec (NB=24.2383 MB/sec 193.907 MBit/sec)
Throughput 16.6765 MB/sec (NB=20.8456 MB/sec 166.765 MBit/sec)
make -j4 bzImage 412.16s user 36.92s system 83% cpu 8:55.74 total
2.5.47-mm2:
Throughput 15.0539 MB/sec (NB=18.8174 MB/sec 150.539 MBit/sec)
Throughput 21.6388 MB/sec (NB=27.0485 MB/sec 216.388 MBit/sec)
make -j4 bzImage 413.88s user 35.90s system 94% cpu 7:56.68 total - fifo_batch strikes again
It's the "doing multiple things at the same time" which gets better; the
straightline throughput of "one thing at a time" won't change much at all.
Corner cases....
Some of the biggest improvements for desktop responsiveness can be found (for Kernel 2.4.x) at Con Kolivas' web site of performance linux patches.
--
quick hint; isnstall the kernel sources that came with your dist. Use the .config file found in this to compile first. These are the settings that your kernel was compiled with. The you can use make xconfig alter a known working config. Good luck.
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
Um, doing benchmarks between an Athlon XP and a Pentium 4 is folly. The P4 has notoriously slow context switching performance. Also, if you are running a small number of threads, your computer isn't spending a whole lot of time thread switching anyway, so the hit doesn't really affect you. When you have lots of threads, scheduling becomes far more important, and so the increase is much more noticible.
A deep unwavering belief is a sure sign you're missing something...
You'll get better interactive performance under load. So if you're encoding an mp3 and writing your home directory to a CD, your mouse cursor won't stick and your windows will refresh reasonably well. Unless you're doing something kind of disk/processor intensive, you won't notice the difference, because 2.4 is too good already for there to be much improvement. If you try to encode 32 mp3s at the same time, 2.6 will actually do worse than 2.4, but at least it won't make ls quite so slow.
The main goals are interactivity (input gets handled quickly), low latency (your mp3 player gets a chance to send the next second of audio to the sound card before this second is over), and fairness (every program makes at least a little progress after a short amount of time).
Overall throughput has not increased (actually, it is believed to have decreased). So the overall speed of the system is relatively equal to the 2.4 series of kernels. You probably won't see any major performance speedups in any apps you use.
However, the overall responsiveness of the system is improved. Most people who have used it have claimed that it felt much faster than the 2.4 series. You won't have starved processess.
This means if you're running XMMS and you compile a kernel, XMMS won't just hang until the compilation is done. The kernel developers have done a great job in improving -fairness- between processes.
Mostly, the results will be seen on Big Iron and server applications, but the overall desktop experience is expected to improve.
It is simple , tar -xvzf linux-{current}.tar.gz.
cd linux; make menuconfig ; make dep bzImage modules modules_install
You're joking, right? How many options in 2.5.47 must be selected in order for your run of the mill $9 generic PS/2 keyboard to work? I can't tell you how much fun it was building 2.5.47, missing one *somewhere* and suddenly I couldn't do anything because my keyboard stopped working.
The kernel only has an expert mode. It would be nice if there were a higher order config that asked you basic questions and built the things you were most likely to need, with the option of going into a more expert mode if you needed to fine tune something.
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
Please write and publish a paper about it!
This is a major breakthrough in computer science.
It also is quite unlikely, since Ahmdahl's law is a trivial observation that is completely independent of parallelization or even software engineering (it also applies to hardware design or even accounting). Basically, it says: if initially only 10% of X (CPU cycles, money, whatever you are trying to save) is spent in the part you are optimizing, there is an upper bound of 10% to the X you can save.
I'm very interested in how you can disprove that.
I don't know about troll, but perhaps just an overactive imagination :)
:)
Apparently he works for a
development firm,
studies meterology,
works for Verizon store at a local mall,
owns a chain of pet stores in London, and
has a thing for CmdrTaco.
Read together, they make amusing reading
I'm a big time VMware user (I use it for testing and Windows). I usually have 2 or 3 VMware machines running at any given time and I have plently of memory (usually 1GB, sometimes more). However, the disk buffer (or disk caching) of Linux sucks ass. I'm not kidding, if I have 1GB of memory, 900+ megs will be used for disk buffers and my very important interactive VMware processes will be swapped out to the slow disk swap file. Just using one of the VMware processes causes a lot of disk I/O and all that I/O gets loaded into the disk buffers in memory then when I go to use another VMware process it has to come out of swap. Linux is pretty bad about this with normal processes, but VMware exasperates the problem.
To boil it down: The disk buffering in 2.4 is way , way too aggressive and I haven't figured out a way to fix it. I need to be able to either limit the total ammount of memory the buffers will use or a better method would be to tag certain processes so that they will never be moved into swap for disk buffers (moving to swap "normally" is OK, just not for disk buffers). Or maybe just make it never swap out any process for disk buffers.
It seems Windows uses a more reasonable disk buffering technique and VMware works better there (especially when using several instances). I don't want to use Windows as my primary OS though because I like the built-in disk encryption and network security of Linux (the ip filter stuff is much better than Windows).
Anyone know if 2.5 has got any better disk buffering?