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."
This was a major reason that 2.5 is, put simply, needed by any and all serious Lunix users.
Based on this image (0202_lab_xp_4.gif), one can see that large volumes of asynchronous I/O is, as the author puts it, the "Achilles' Hell" of Linux.
The Linux kernel itself in all versions 2.5 serializes disk Input/Output with a single spinlock.
(The yellow is the Windows XP box; the green line is the data for the SuSE Linux pee sea)
--
Department of Physics and Atmospheric Science, Dalhousie University, Halifax, N.S., Canada, B3H 3J5
This is This is the exact opposite of my findings.
by
Professor+Collins
·
· Score: 1, Troll
When I first heard about some of the things going on in the 2.5 branch,
such as the newly tuned VM system, improved filesystem code, and especially
Ingo Moyar's O(1) scheduler project, I was ecstatic. The
promise of an average workstation computer handling 100,000 threads with as
much grace as it handles 100 sounded too good to be true. And alas, it was.
There are a number of serious problems with Linux 2.5's scalability pushes,
trading performance for normal tasks in order to run better at more esoteric
tasks, and many of these can be traced back to the new O(1) scheduler.
A month ago, I downloaded the 2.5.44 kernel, and have been benchmarking it
extensively on one of the Pentium 4 2GHz workstations in the computer lab. For
a control, I ran a stock 2.4.19 kernel on the Athlon XP 2000+ machine next to
it. My test consisted of running an increasing number of parallel processes
each executing a for(;;) loop repeatedly nanosleep(2)ing for 10ms, thus
yielding the scheduler every time they awake. This made sure that the scheduler
was more or less the only thing running on the system, and that I could get an
accurate count of the average task-switching time.
By gradually increasing the number of threads on each machine in parallel, I
was able to graph the comparative performance of the two schedulers. The results
do not bode well for the new scheduler: (forgive my somewhat clumsy approximation, text is not the best medium for graphic content)
S |
c | . O(n) scheduler (2.4.19)
h |.
e |.
d |-----.------- O(1) scheduler (2.5.44)
T | . |
i | |
m | |p
e |_______|_______
No. of Threads
As you can see, the new scheduler is in fact O(1), but it adds so much initial
overhead that task switching is slower than under the old scheduler until you
have a certain number of threads, labeled p above. My benchmarking
experiments put p at around 740 threads.
Now, this is obviously good
for high-end applications that run thousands of processes concurrently, but
the average Linux user rarely has more than 100 processes on his machine at a
time. The vast majority of servers rarely exceed more than 250 concurrent
processes. In these cases, the O(1) scheduler is cutting their computer's
performance almost in half.
What we're seeing here is the likes of IBM and Sun
putting their needs before those of the hobbyist hackers and users who make
up the majority of the Linux user base. While the O(1) scheduler project is
a noble cause and should certainly be made available as an option for
those few applications that benefit from it, outright replacing the old
scheduler at this point is a folly.
I've actually contributed several patches to the SMP cycle router in the new 2.5.47 kernel. Me, as well as several of my associates, have had the privilege of testing Linux on our quad-proc machines at our development firm where we work. The speed is absolutely marvelous, my manager's jaw dropped when he saw how fast we could compile our corporation's PHP scripts.
On the video front, the bus core of the latest AGP 8x cards are now implemented with dual-feed data ports, as BSD has implemented in their last main release. This increases the pixels per second speed by order of magnitudes, all with about two hours worth of code tweaking.
As a side note, however, I recommend if you want to try these significant kernel improvements on your boxen at home, please use extreme caution - the stability of these releases are questionable, and they have been known to cone dump into various output files. Please, do not deploy this on mission critical desktops or NT workstations!
By the looks of it, the Linux 2.5 kernel is ahead of schedule, and it looks as though it may be fully ready by year-end 2002. How's that for a Christmas present!
What is your degree, Professor? BS?
by
FreeLinux
·
· Score: 0, Troll
You ran an experiment to test two different kernels and used two totally different processors? Don't you think that you should have been using identical hardware for this test?
Your "testing" is of no value at all. That is, if you actually did these tests. I suspect this is simply a crafty little troll.
Slashdot Mirror
This was a major reason that 2.5 is, put simply, needed by any and all serious Lunix users.
Based on this image (0202_lab_xp_4.gif), one can see that large volumes of asynchronous I/O is, as the author puts it, the "Achilles' Hell" of Linux.
The Linux kernel itself in all versions 2.5 serializes disk Input/Output with a single spinlock.
(The yellow is the Windows XP box; the green line is the data for the SuSE Linux pee sea)
Department of Physics and Atmospheric Science, Dalhousie University, Halifax, N.S., Canada, B3H 3J5
A month ago, I downloaded the 2.5.44 kernel, and have been benchmarking it extensively on one of the Pentium 4 2GHz workstations in the computer lab. For a control, I ran a stock 2.4.19 kernel on the Athlon XP 2000+ machine next to it. My test consisted of running an increasing number of parallel processes each executing a for(;;) loop repeatedly nanosleep(2)ing for 10ms, thus yielding the scheduler every time they awake. This made sure that the scheduler was more or less the only thing running on the system, and that I could get an accurate count of the average task-switching time.
By gradually increasing the number of threads on each machine in parallel, I was able to graph the comparative performance of the two schedulers. The results do not bode well for the new scheduler: (forgive my somewhat clumsy approximation, text is not the best medium for graphic content)
As you can see, the new scheduler is in fact O(1), but it adds so much initial overhead that task switching is slower than under the old scheduler until you have a certain number of threads, labeled p above. My benchmarking experiments put p at around 740 threads.Now, this is obviously good for high-end applications that run thousands of processes concurrently, but the average Linux user rarely has more than 100 processes on his machine at a time. The vast majority of servers rarely exceed more than 250 concurrent processes. In these cases, the O(1) scheduler is cutting their computer's performance almost in half.
What we're seeing here is the likes of IBM and Sun putting their needs before those of the hobbyist hackers and users who make up the majority of the Linux user base. While the O(1) scheduler project is a noble cause and should certainly be made available as an option for those few applications that benefit from it, outright replacing the old scheduler at this point is a folly.
On the video front, the bus core of the latest AGP 8x cards are now implemented with dual-feed data ports, as BSD has implemented in their last main release. This increases the pixels per second speed by order of magnitudes, all with about two hours worth of code tweaking.
As a side note, however, I recommend if you want to try these significant kernel improvements on your boxen at home, please use extreme caution - the stability of these releases are questionable, and they have been known to cone dump into various output files. Please, do not deploy this on mission critical desktops or NT workstations!
By the looks of it, the Linux 2.5 kernel is ahead of schedule, and it looks as though it may be fully ready by year-end 2002. How's that for a Christmas present!
You ran an experiment to test two different kernels and used two totally different processors? Don't you think that you should have been using identical hardware for this test?
Your "testing" is of no value at all. That is, if you actually did these tests. I suspect this is simply a crafty little troll.