In this blog entry, I try to investigate easy methods to get a “faster” kernel.
Measure
The time of five events are measured:
- [1] (printk timing) A very early kernel message, “ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]”
This message is buffered until syslog starts, so its date information in /var/log/messages can not be used. The following event allows a conversion between the two timings. - [2] (printk timing and date from syslog) The first message when the kernel executes userland: “Adding 2047888k swap on /dev/hda5″
- [3] (date from syslog) first userland daemon message: “acpid: starting up with proc fs”
- [4] (date from syslog) first X program message: (seahorse makes a call to gpgme)
- [5] (date) a program run by the GNOME session messenger stores the output of date +%S.
make clean was performed before each recompile.
System
Gentoo Linux, 64bit, 2.6.30-gentoo-r4 kernel, quite normal End-user system with the GNOME Desktop. HP Pavilion dv8000 single-cpu 2GHz, 1GB RAM.
Optimizing with -O3, -O2 or -Os?
People from Gentoo, GCC, the LKML and many others will tell you that using -O3 is not a good idea. Furthermore, O3 it is known to make the kernel instable.
So let’s try it anyway, and for the fun of it, add -march=native after -m64. We also allow GCC to uninline functions marked as inline.
I can look at the time differences (in seconds, y-axis) between the events (deltas), relative to one optimization (I chose -Os), and absolute times (zero being system boot):
A average over 3 boot was taken, and the error bars show the standard deviation. Usually, you should take a dot that lies out 3 times the standard deviation seriously. If you now want to complain that you can’t see the dots in the graph, you are missing the point: The standard deviation is way larger than the difference between the averages.
=> It makes absolutely no difference whether you compile the kernel -O3, -O2 or -Os.
But: I ran into trouble with -O3, as the cpufreq sysfs-interface hung (blocked io).
Preemption
I keep the -Os kernel.
Three options are given for the kernel preemption model: No forced preemption (“preempt”), Voluntary Kernel Preemption (default), preemptible kernel (“no-preempt”). Get more information in menuconfig or the kernel documentation.
Again, the same diagrams as above:
One might have the feeling that a preemptible kernel is slower during kernel boot, but faster when executing the userland startup. But again, the standard deviation is way to big, one can not draw a definite conclusion, none of the options out-performs the other.
To make the point clear, the difference between the average boots is less than a second (and yes, this system boots in 60 seconds into the GNOME desktop).
Pretty boring so far, but how would a significant result look like, then?
Scheduler
I keep the preemptible, -Os kernel.
The kernel got a new scheduler a while ago, CFQ (Completely fair scheduler). (This also gave us the beautiful program ionice).
There are 4 schedulers available, they can be selected by the kernel parameter “elevator=…”: Anticipatory, Deadline, CFQ and No-op. Get more information about them in menuconfig or the kernel documentation.
Now that’s a real difference: CFQ boots around 9 seconds faster than the others, the standard deviation is around less than 2 seconds.
=> CFQ is superior to the other schedulers in this scenario.
“Unfortunately”, CFQ is already the default scheduler, so the default kernel is already the best choice. Good to know.
All used kernel configs are available as a tar file. You can play with the numbers using the gnumeric file.
Watching the disk light, a program like readahead (keeps file content in memory) should be the way to improve startup speed. In my setup, using readahead-list did not change the boot up time.
Parallel boot services (RC_PARALLEL_STARTUP) managed to squeeze out 2-3 seconds to a final boot time of around 58 seconds. At the end you learn the best tools … bootchart for example.
Recent Comments