kernel compile benchmarks ...

I am getting my feet wet with SCSI and I got to try two used and real cheap (free) SCSI drives in my system. I already had a LSI SCSI controller so I figure lets give this a try. In the future I want to run the Seagate 15K.3 15K RPM U320 SCSI drives but I have to save some money for those. In the mean time, this "slow" and "old" SCSI drive will do.

The one thing (and I kind of expected this), my system is a little bit slower with these particular SCSI drives, when compared to my prior IDE drive (Maxtor Diamond Plus 60GB, 7200RPM, ATA133, 8MB buffer). The reason I know is by timing the compile times (kernel 2.4.22). I have made some experiments with one and two processors over the last couple of months, at different levels of overclocking, and here are my results so far (system at idle, no other user processes running, no open apps, etc.):

1) Original benchmark: IDE Drive, 2 Athlon CPU's at 2000Mhz, running "make bzImage" => 3 and 1/2 minutes

2) Same as 1 but running "make -j 2 bzImage" => 2 minutes even

3) Just one Athlon, but at 2260Mhz, running "make -j 2 bzImage" => 3 and 1/2 minutes

4) Two Athlons, each at 2260Mhz, still on IDE drive, running "make -j 2 bzImage" => 1 minute 45 seconds (fastest yet)

5) New-to-me SCSI drive (9GB, U160, 10K RPM, 2MB buffer), 2 CPU's at 2260Mhz, running "make -j 2 bzImage" => 2 minutes 6 seconds

So not a huge difference between 4 and 5 (21 seconds), but percentage-wise, a noticeable difference. The system from my point of view (booting, opening/closing apps, etc.) seems to be about the same as before - not fast enough for me.

I hope that once I go to 15K RPM, 8MB buffer Seagate 15K.3's my overall system will feel "speedier".

William

In the 2.6 kernels, you can do make allyesconfig. Guess what it does.

edit: When you take a measurement, the margin of error is just as important as the measurement itself. Before jumping to conclusions, you should always repeat a test about 3-6 times and take the average (and find the standard deviation, if you're really geeky).
It's also possible that there are some SCSI options that could use tuning.
Finally, make sure that both drives are running the same filesystem. Changing the filesystem can make a significant difference.

Ther eis simply no CPU in the world today which can compile a kernel in 2 minutes. just not possible
What you did was probably just compiling a few single files which are always compiled everytime and then linking the kernel, not all of it. you have to start a kernel compile benchmark with "make clean" everytime first

klingens,

I use a 30MB source kernel file from Xandros (xandros-kernel-source-2.4.22.tar.bz2). Here are all of the steps I do:

1) copy kernel source file to test_kernel directory
2) tar -xjf file
3) cd into new expanded dir
4) copy excisting .config to new kernel dir
5) make menuconfig (change generic CPU to Athlon and change reiserfs from module to built-in)
6) make dep
7) make clean
8) make bzImage

I delete this test directory and start from scratch every single time. The times I gave are for running step 8 only, which is the longest step on my machine. Hundreds if not thousands of files fly back on the screen non-stop while this is compiling. It is certainly not just a few files.

I don't claim to be an expert, but these are the times I measured on my machine (see SIG). Any suggestions as to what I might be doing wrong that would make for such short compile times?

William


EDIT: Could the files that I see flying through the screen mean that files are being skipped perhaps? Would that explain the short times?

Try running "make clean" before you do that to remove whatever object files may be lying around (I'm not familar with Xandros kernel distributions). You'll probably notice an increase in build times after running make clean, as klingens said. Note that you need to clean the tree before each compile to get accurate results.

To remove some of the tedium, you can run this script, which will get/use the 2.6.5 kernel with make allyesconfig. If that doesn't increase your compile time, I don't know what will. It will also only display the output of time so that you won't waste any time staring at the output.
When you use your kernel compile time as a benchmark, you need to use the same .config file as everyone else. Otherwise you could just use a minimal .config and have a faster computer than everyone else.

cool - thanks Christoph. My guess is that the process I am doing is skipping through a lot of files instead of compiling them all, even though I do delete the directory and start all over again.

Your script is different from what I have been doing, but I will use it from now on everytime I need to check system changes.

What do I have to do to re-run it? Go to /usr/src and delete all of the new files in the linux-2.6.5 directory?

OK, I now had time to run the new script that Christoph gave me. Among some compile errors, the last 3 lines were:

< snip>

real 24m44.365s
user 20m35.880s
sys 2m52.880s
Workstation:/home/william#

I guess that means that it took 24 minutes 44.37 seconds to do everything, right? (I am not sure how to read those 3 lines - never used that time command).

If I want to run this again in order to compare back-to-back runs, do I first delete the newly created directory, right?

If you want to run the script more than once, you can just re-run it although it will be faster if you delete the tar line.
I didn't really mean for this to be any kind of definitive script. It's just a quick hack to ensure easy consistancy. There's a lot of room for improvement and greater consistency (ie you shouldn't be getting errors and there should be some detection if the script's been run before). Also, make sure that you didn't run out of space. It looks like using allyesconfig requires a lot of it.

thanks much Christoph and others who replied - I learned several new things about Linux on this thread

You're welcome.