Description of problem: On the identical hardware, RHEL 5 Xen-enabled kernel is 20% or more slower than RHEL 4.x Version-Release number of selected component (if applicable): 2.6.18-8.1.8.el5xen How reproducible: Consistently. On HP dx5150 or Dell Precision 390. Steps to Reproduce: 1. Use two identical machines or load RHEL4 run tests first and then reload with RHEL 5 and run the same tests as below 2. Untar kernel-2.6.22.5 to a scratch directory on local disk 3. Run "cd /tmp/linux-2.6.22.5; make oldconfig", then run "time make". Actual results: RHEL5 takes 20% or longer to finish compiling the same kernel than RHEL4. Expected results: RHEL5 takes same amount of time or less to compile linux kernel as RHEL4. Additional info:
Here are some test results: $ time tar -zxvf linux-2.6.22.5.tar.gz RHEL5 Non-xen kernel real 0m4.330s user 0m3.226s sys 0m2.932s Xen kernel real 0m4.009s user 0m2.448s sys 0m2.248s RHEL4 real 0m6.685s user 0m2.657s sys 0m3.516s $ time make RHEL5 Non-xen kernel real 28m5.217s user 25m47.617s sys 4m0.718s Xen kernel real 30m2.323s user 24m14.195s sys 5m25.640s RHEL4 real 18m44.957s user 16m17.779s sys 2m17.887s
You probably wanted to select a component "kernel".
RHEL5 Non-xen kernel real 28m5.217s Xen kernel real 30m2.323s RHEL4 real 18m44.957s So, RHEL-5 is actually something like 50% slower here. But... this does not look like a kernel issue. It's certainly not a Xen issue, as the difference between the RHEL-5 xen and non-xen kernels is tiny compared to the difference between RHEL-4 and RHEL-5. But RHEL-5 has a newer compiler that is doing more, and different, optimisations; it is entirely reasonable that it may take longer for some jobs. Indeed, the numbers above show that the bulk of the difference is accounted for in user time, ie. time spent in the compiler, not the kernel. We cannot consider this to be a kernel issue unless it is the same compiler version being tested in each case.
RHEL4 has gcc 3.4, which had only RTL optimization passes, gcc 4.1 has both tree-SSA and RTL optimization passes, so roughly 100 new optimization passes. While a lot of work has been done to improve compile speed and it is still ongoing (e.g. GCC 4.3 will have some compile time speed improvements), some slowdown from 3.4.x is to be expected. You get for that price better optimized code in many cases and also some new GCC extensions that aren't really doable on the RTL representation (e.g. -D_FORTIFY_SOURCE with gcc 3.4.x is orders of magnitude worse protection than in gcc 4.0.x+).