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 [story] saying, "Short summary: we mostly rock."
He goes on to explain that the following results show 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. Read on for the raw data.
From: Cliff White [email blocked] To: linux-kernel Subject: 2.6.0-test5-mm3/mm4 - osdl-aim-7 Date: Mon, 22 Sep 2003 13:38:15 -0700 Short summary: we mostly rock. - latest 2.4 is better at UP, worse at SMP vs 2.5 - mm3/4 and stock -test5 now very close for most loads, Full data, including elevator comparisons, at: http://developer.osdl.org/cliffw/reaim/index.html stp1 CPU machine STP id PLM# Kernel Name MaxJPM MaxU Change Host Options Newest Kernel - Baseline for % change - Workfile new_dbase 280322 2160 2.6.0-test5-mm4 990.48 17 0.00 stp1-000 profile=2 279455 2110 linux-2.6.0-test5 992.06 17 0.16 stp1-003 profile=2 280264 2159 patch-2.4.23-pre5 1067.19 18 7.74 stp1-003 profile=2 Newest Kernel - Baseline for % change - Workfile compute 280323 2160 2.6.0-test5-mm4 1014.33 17 0.00 stp1-001 profile=2 279456 2110 linux-2.6.0-test5 1017.43 17 0.31 stp1-000 profile=2 280265 2159 patch-2.4.23-pre5 1080.85 18 6.55 stp1-000 profile=2 stp2 CPU machine STP id PLM# Kernel Name MaxJPM MaxU Change Host Options Newest Kernel - Baseline for % change - Workfile new_dbase 280349 2160 2.6.0-test5-mm4 1335.58 22 0.00 stp2-001 profile=2 279886 2112 linux-2.6.0-test5 1332.15 22 -0.25 stp2-001 profile=2 280291 2159 patch-2.4.23-pre5 1301.73 22 -2.53 stp2-001 profile=2 STP id PLM# Kernel Name MaxJPM MaxU Change Host Options Newest Kernel - Baseline for % change - Workfile compute 280350 2160 2.6.0-test5-mm4 1502.61 24 0.00 stp2-001 profile=2 279475 2110 linux-2.6.0-test5 1545.03 26 2.82 stp2-002 profile=2 280292 2159 patch-2.4.23-pre5 1485.33 24 -1.14 stp2-001 profile=2 stp4 CPU machine STP id PLM# Kernel Name MaxJPM MaxU Change Host Options Newest Kernel - Baseline for % change - Workfile new_dbase 280236 2155 2.6.0-test5-mm3 5365.30 92 0.00 stp4-000 profile=2 279883 2110 linux-2.6.0-test5 5406.68 92 0.77 stp4-000 profile=2 STP id PLM# Kernel Name MaxJPM MaxU Change Host Options Newest Kernel - Baseline for % change - Workfile compute 280237 2155 2.6.0-test5-mm3 5208.20 88 0.00 stp4-000 profile=2 279493 2110 linux-2.6.0-test5 5175.28 88 -0.63 stp4-000 profile=2 stp8 CPU machine STP id PLM# Kernel Name MaxJPM MaxU Change Host Options Newest Kernel - Baseline for % change - Workfile new_dbase 280188 2155 2.6.0-test5-mm3 8317.55 136 0.00 stp8-000 profile=2 279444 2110 linux-2.6.0-test5 8785.24 144 5.62 stp8-002 profile=2 279826 2141 patch-2.4.23-pre4 6888.10 112 -17.18 stp8-000 profile=2 STP id PLM# Kernel Name MaxJPM MaxU Change Host Options Newest Kernel - Baseline for % change - Workfile compute 280189 2155 2.6.0-test5-mm3 9745.39 160 0.00 stp8-000 profile=2 279445 2110 linux-2.6.0-test5 9758.11 160 0.13 stp8-002 profile=2 279057 2090 patch-2.4.23-pre3 9838.69 160 0.95 stp8-002 profile=2 ------------------ cliffw --------------- Detail on any run: http://khack.osdl.org/stp/<STP id> Hardware details: http://khack.osdl.org/stp/<STP id>/environment/machine_info More results: http://developer.osdl.org/cliffw/reaim/index.html --------------- Code location: bk://developer.osdl.org/osdl-aim-7 tarball: http://sourceforge.net/projects/re-aim-7 Run parameters: ./reaim -s$CPU_COUNT -x -t -i$CPU_COUNT -f workfile.new_dbase -r3 -b -l./stp.config ./reaim -s$CPU_COUNT -q -t -i$CPU_COUNT -f workfile.new_dbase -r3 -b -l./stp.config (3 runs each, average of all 6 reported) cliffw
i can feel it
Now with 2.6.0-test5-bk11 i can compile at 99% cpu load and browse the web flawlessly.
Scheduler
That would be because Con's O20.3int patch made it into mainline :-)
O1int
Thanks Nero for pointing that out. Your ability to use your machine as a desktop under load should be significantly enhanced now that my interactivity patch has been merged. I'm happy it works well for you.
Desktop benchmarks
I think it'd be interesting to see things like Vorbis encoding times and, benchmarks of popular 3D games, like UT2003, etc, now that Linux is making more serious desktop headway.
Not so relevant
CPU speeds are and have been for a long time high enough that it does not make sense to optimise for these sorts of things in the kernel. Most of the single CPU performance drop is probably due to HZ = 1000, but you can afford to make these tradeoffs because they can provide big improvements elsewhere.
An interesting desktop benchmark, of course, is one where lots of things are being done at once. Desktop users don't care if they can get another 2fps in UT, or have their mp3 encoder finish in 3s less. They really get shitty if their mp3 player skips, or their mouse stutters.
Absolutely
Indeed; it was embarassing that test5 and before could skip audio on even the most modern uniprocessor hardware even though it was using less than 1% cpu time for the audio decoding. However there are some people who care about those last 2fps (I dont understand why but that's their perogative).
By the way, nice job Con
Well done for getting your interactivity work into the kernel.
A big "thank you" to both, Ni
A big "thank you" to both, Nick and Con. I ran test5 for > 1 week and am currently running test5-O1int for ~3 days now. And I'm feeling the difference. Con's work really has made using desktops better. I still get some audio skips, unresponsive X (or mouse stutters) every now and then, but it's definitely better than plain test5.
I really hope interactivity is there
Iäm sceptical. I downloaded a redhat-friend 2.6-kernel and installed it.
Iteractivity was poor; worse than my 2.4-kernel....
we'll see I guess :-)
Wrong kernel version
The redhat rpms are of the vanilla kernel which (until test6) does not contain the interactivity patches. Try again with test6 when it comes out or you can give the -mm patchset a try.
Thanks!
Cheers.
2 fps
However there are some people who care about those last 2fps (I dont understand why but that's their perogative).
Because for them it's nearly 10% of what they get.
I used to play quake1/quake3arena on kernel 2.4 with about 40 fps.
Then I made a long pause in gaming, about one year. Then few months ago I've run quake on 2.5.x. Horrible. I seldom get more than 20 fps. Twenty! Half of previous framerate. It's all on Celeron 366 with Matrox G550. Something is really fucked up.
I haven't tried latest test5-bk yet.
--
:wq
That's why it's called test5.
That's why it's called test5.
X renicing
I don't know if I'm stating something everyone already knows, but I guess it won't hurt to mention it again.
Some distros (at least Debian, maybe others) ship X with a default configuration where it is forced a nice value of -10. As far as I've understood, this new interactivity stuff does the right thing only if X runs at 0 with no recining done to either direction. Changing the default nice value from -10 to 0 should fix the situation for distros that ship reniced X.
2fps
Sometimes I just have to state the bleedingly obvious to not be taken out of context. If 2fps is a significant percentage of your frame rate then of course it matters. I'm talking about the people who get glxgears fps of 1500 or more and complain about the loss of 2fps there.
What About Load?
Perhaps in raw benchmarks 2.4 is faster then 2.6 under UP but what about under load? With the new bio layer, I/O scheduler, process scheduler, threading implementation, new VM, TCP/IP improvements, etc Linux outa handle heavy loads like a champ. Under load Linux historically falls apart while others, like FreeBSD or Solaris, will continue to crunch on. I'd suspect with all the thorough changes that 2.6 outa handle stressful loads much more gracefully. So, yeah, I'd think even on UP 2.6 has lots of advantages.
~Christopher X
Frame Rate, Perceived Latency
Howdy
Is the scheduling the biggest FPS bottle neck in a modern GNU/Linux distro?
Surely X would have to be to blame or is X rather good at it`s job, also interactivity, i here alot about the scheduler but what about KDS or Gnome, surely these would be the source of alot of problems.
Am I missing something here?
nvidia + minion patch + 2.6.0-test5-mm4 = not working
The X server failed to load, complaining about config DMA
Soft RealTime status
On a related subject, does anyone know about the SCHED_FIFO/SOTFRR
status in 2.6 ? I'm a Linux Audio user and this field _requires_ that
you can feed or read your audio interface when it needs to be fed or
read. For now with 2.4, you have to run your apps (mainly the Jackd
sound server) as root or using a patched kernel with capabilities, in
order to set the scheduler priority to SCHED_FIFO. With a buggy app
that can lead to a hard lockup of your system. Scheduler requirements
for serious audio work differ from just "I don't want xmms to skip
while I use mozilla and build a new kernel".
Thanks !
Debate rolled on
There was a lot of debate over this and the conclusion was that if you need true real time performance you may as well use fully real time capable apps. The softRR idea was to give user access to real time performance without giving a normal user the ability to starve the system - unfortunately that means that at times it wasn't real time; meaning that under stress it performed no better than a tuned normal scheduler, and when not under stress a normal scheduling policy is adequate anyway (yes I know the scheduling latency will be greater but unlikely to make a performance difference except in "benchmarks"). Feel free to start another debate here but that's where it stands.
At this stage I can tell you with some certainty there will be no softRR in the mainline 2.6.0 kernel when it is released. The real time capabilities of 2.6 kernels will be of lower latency than 2.4 kernels. Of course there will be alternate trees faster than you can say Andrea Arcangeli, but that's another story.
Thanks for replying Con. I
Thanks for replying Con.
I hope 2.6 will behave well in this area. Linux Audio Development is
really gaining momentum these days. Talented and dedicated programmmers
are working hard to kick other OSes out of recording studios ;) Maybe
a kernel guru will take LAD's requirements into account (Andrew Morton's
LL patches for 2.4 were really needed and much welcomed).
Keep up the good work !