Last time I tested it was on dapper release and the k7 kernel booted my athlon more than 5 secs faster then 386. I'm the kind of user who reboots a lot and I found those seconds pretty precious.<br>Just my half cent.<br><br>
<div><span class="gmail_quote">On 8/14/06, <b class="gmail_sendername">Matt Zimmerman</b> <<a href="mailto:mdz@ubuntu.com">mdz@ubuntu.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
== Background ==<br><br>You've all seen our kernel lineup before. In the beginning, on i386 we had<br>linux-386, linux-686, linux-k7, linux-686-smp, linux-k7-smp. Later, we<br>added specialized server kernels, and folded SMP support into linux-686 and
<br>linux-k7.<br><br>Since Linux has always offered CPU-specific optimizations, it's been taken<br>for granted that this offered enough of a performance benefit to make all of<br>this maintenance effort worthwhile. A lot has happened to the kernel since
<br>the early days, though, and for some time, it has been capable of loading<br>these optimizations at runtime. Even when you use the -386 kernel, you get<br>the benefit of many CPU-specific optimizations automatically. This is great
<br>news for integrators, like Ubuntu, because we want to provide everyone with<br>the best experience out of the box, and as you know, there isn't room for so<br>many redundant kernels on the CD (only one). Many users spend time and
<br>bandwidth quotas downloading these optimized kernel in hopes of squeezing<br>the most performance out of their hardware.<br><br>This begged the question: do we still need these old-fashioned builds?<br>Experiments have shown that users who are told that their system will run
<br>faster will say that they "feel" faster whether there is a measurable<br>difference or not. For fun, try it with an unsuspecting test subject: tell<br>them that you'll "optimize" their system to make it a little bit faster, and
<br>make some do-nothing changes to it, then see if they notice a difference.<br>The fact is, our observations of performance are highly subjective, which is<br>why we need to rely on hard data.<br><br>== Data ==<br><br>Enter Ben Collins, our kernel team lead, who has put together a performance
<br>test to answer that question, covering both the i386 and amd64<br>architectures. The results are attached in the form of an email from him.<br>Following that is a README which explains how to interpret the numerical<br>
figures.<br><br>No benchmark says it all. They're all biased toward specific workloads, and<br>very few users run a homogenous workload, especially not desktop users.<br>This particular benchmark attempts to measure system responsiveness, a key
<br>factor in overall performance (real and perceived) for desktop workloads,<br>which are largely interactive.<br><br>== Conclusion ==<br><br>Having read over it, I think the numbers are fairly compelling. The<br>difference in performance between -386 and -686 is insigificant; the
<br>measurements are all within a reasonable error range, and within that range,<br>-686 was slower as often as it was faster.<br><br>My recommendation is that we phase out these additional kernel builds, which<br>I expect will save us a great deal of developer time, buildd time, archive
<br>storage and bandwidth.<br><br>I'm interested to hear (objective, reasoned) feedback on this data and my<br>conclusions from the members of this list.<br><br>--<br> - mdz<br><br><br><br>---------- Forwarded message ----------
<br>From: Ben Collins <<a href="mailto:bcollins@ubuntu.com">bcollins@ubuntu.com</a>><br>To: <a href="mailto:mdz@ubuntu.com">mdz@ubuntu.com</a><br>Date: Mon, 14 Aug 2006 19:58:22 -0400<br>Subject: Benchmarks between generic and cpu specific kernel images
<br>Test was performed on an Intel Pentium 4, 2Ghz system with 256Mb of RAM.<br>I consider this about average for our users. The test I ran was<br>"contest", which basically builds a kernel under several different load
<br>types. It's meant specifically for comparing different kernels on the<br>same machine. Each one of the lines below represents the average of 3<br>kernel builds under that particular type of stress. The first two are<br>
baseline results (cache run is just no_load without clearing the<br>mem/disk cache, the rest of the results have the mem/disk cache cleared<br>before starting).<br><br>Here's the results:<br><br>no_load:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio
<br>2.6.17-6-386 3 73 87.7 0.0 0.0 1.00<br>2.6.17-6-686 3 73 89.0 0.0 0.0 1.00<br><br>cacherun:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio<br>2.6.17-6-386
3 65 98.5 0.0 0.0 0.89<br>2.6.17-6-686 3 66 97.0 0.0 0.0 0.90<br><br>process_load:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio<br>2.6.17-6-386 3 143
44.8 260.0 52.4 1.96<br>2.6.17-6-686 3 144 44.4 230.0 52.8 1.97<br><br>ctar_load:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio<br>2.6.17-6-386 3 100 67.0 8.7
10.0 1.37<br>2.6.17-6-686 3 97 69.1 6.3 9.3 1.33<br><br>xtar_load:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio<br>2.6.17-6-386 3 96 67.7 2.0 4.2
1.32<br>2.6.17-6-686 3 96 68.8 1.7 4.1 1.32<br><br>io_load:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio<br>2.6.17-6-386 3 102 64.7 11.3 5.9 1.40<br>2.6.17-6-686
3 103 66.0 12.1 8.3 1.41<br><br>io_other:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio<br>2.6.17-6-386 3 94 71.3 20.9 12.8 1.29<br>2.6.17-6-686 3 97
70.1 21.3 16.3 1.33<br><br>read_load:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio<br>2.6.17-6-386 3 91 72.5 2.3 2.2 1.25<br>2.6.17-6-686 3 92 72.8 2.3
2.2 1.26<br><br>list_load:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio<br>2.6.17-6-386 3 87 75.9 0.0 5.7 1.19<br>2.6.17-6-686 3 87 77.0 0.0 6.9
1.19<br><br>mem_load:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio<br>2.6.17-6-386 3 327 20.5 74.0 0.6 4.48<br>2.6.17-6-686 3 390 17.7 80.7 0.8 5.34<br><br>
dbench_load:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio<br>2.6.17-6-386 3 83 78.3 52193.3 18.1 1.14<br>2.6.17-6-686 3 92 71.7 47986.7 23.9 1.26<br><br><br>Using this as a guide, you can see that the difference is only
<br>negligible. The -686 targeted kernel does not gain or lose any<br>significant performance on this test system. The mem_load was the only<br>noticeable change, where the -686 kernel shows worse performance. This<br>may be specific to my system. The individual results are here:
<br><br>2.6.17-6-386 58 9 157 764901 883 mem_load 0 2 158 182219 5893 7100<br>2.6.17-6-386 58 10 381 780220 4597 mem_load 0 3 382 191532 8976 7600<br>2.6.17-6-386 59 10 445 780181 6654 mem_load 0 2 446 191709 8501 7500<br>
2.6.17-6-686 58 11 244 771704 1849 mem_load 0 3 244 192658 7983 7600<br>2.6.17-6-686 58 12 445 788730 6357 mem_load 1 3 446 198200 9831 8100<br>2.6.17-6-686 59 12 481 793676 6401 mem_load 1 3 482 200208 11464 8500<br><br>
You can see in the 4th column the major changes in the results of the<br>first run for each kernel. The results after the first run seem more<br>likely to be correct.<br><br>I also performed the same test on an SMP Xeon machine (2 x Core2Duo @
<br>3ghz), using the amd64-generic and amd64-xeon kernel images. Here's the<br>results for that:<br><br>no_load:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio<br>2.6.17-7-amd64-generic 3 49
357.1 0.0 0.0 1.00<br>2.6.17-7-amd64-xeon 3 47 370.2 0.0 0.0 1.00<br><br>cacherun:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio<br>2.6.17-7-amd64-generic 3 48
362.5 0.0 0.0 0.98<br>2.6.17-7-amd64-xeon 3 47 368.1 0.0 0.0 1.00<br><br>process_load:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio<br>2.6.17-7-amd64-generic 3 60
285.0 131.0 95.1 1.22<br>2.6.17-7-amd64-xeon 3 60 285.0 130.0 96.7 1.28<br><br>ctar_load:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio<br>2.6.17-7-amd64-generic 3 55
320.0 15.7 25.5 1.12<br>2.6.17-7-amd64-xeon 3 54 325.9 15.3 25.9 1.15<br><br>xtar_load:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio<br>2.6.17-7-amd64-generic 3 51
343.1 1.7 5.9 1.04<br>2.6.17-7-amd64-xeon 3 53 330.2 2.3 7.5 1.13<br><br>io_load:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio<br>2.6.17-7-amd64-generic 3 101
171.3 3.8 5.9 2.06<br>2.6.17-7-amd64-xeon 3 97 179.4 3.7 5.6 2.06<br><br>io_other:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio<br>2.6.17-7-amd64-generic 3 115
150.4 3.8 5.9 2.35<br>2.6.17-7-amd64-xeon 3 103 168.0 3.7 5.5 2.19<br><br>read_load:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio<br>2.6.17-7-amd64-generic 3 89
194.4 0.4 0.0 1.82<br>2.6.17-7-amd64-xeon 3 93 186.0 0.4 0.0 1.98<br><br>list_load:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio<br>2.6.17-7-amd64-generic 3 49
357.1 0.0 2.0 1.00<br>2.6.17-7-amd64-xeon 3 53 328.3 0.0 0.0 1.13<br><br>mem_load:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio<br>2.6.17-7-amd64-generic 3 54
338.9 3137.0 38.9 1.10<br>2.6.17-7-amd64-xeon 3 54 337.0 3155.3 38.9 1.15<br><br>dbench_load:<br>Kernel [runs] Time CPU% Loads LCPU% Ratio<br>2.6.17-7-amd64-generic 3 84
211.9 0.0 0.0 1.71<br>2.6.17-7-amd64-xeon 3 86 207.0 0.0 0.0 1.83<br><br>The only significant different was in the io_other performance. The<br>io_other test involves some random I/O operations on a large file. I
<br>think the difference here is real. However, given that our -server<br>kernel will likely get back the small loss should be enough to warrant<br>still converting to generic kernels for amd64 and i386.<br><br>I can make this happen using linux-meta to handle the upgrades (next
<br>kernel upload is an ABI bump, so would be perfect timing along with lrm<br>and linux-meta).<br><br>Question is, do we want...<br><br>linux-image-2.6.17-7-generic<br>(or just)<br>linux-image-2.6.17-7<br><br>...for both i386 and amd64? I prefer the no-flavor version, but it would
<br>require some slight changes in the build system.<br><br>I want to change the amd64 kernels to be less amd64ish, and have just<br>two kernels:<br><br>linux-image-2.6.17-7{,-generic}<br>and<br>linux-image-2.6.17-7-server
<br><br>That way there's more consistency in the naming with i386, and i386<br>would just have the extra -server-bigiron.<br><br>--<br>Ubuntu - <a href="http://www.ubuntu.com/">http://www.ubuntu.com/</a><br>Debian -
<a href="http://www.debian.org/">http://www.debian.org/</a><br>Linux 1394 - <a href="http://www.linux1394.org/">http://www.linux1394.org/</a><br>SwissDisk - <a href="http://www.swissdisk.com/">http://www.swissdisk.com/</a>
<br><br><br>--<br>ubuntu-devel mailing list<br><a href="mailto:ubuntu-devel@lists.ubuntu.com">ubuntu-devel@lists.ubuntu.com</a><br><a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel">https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
</a><br><br><br><br></blockquote></div><br>