optimised kernel howto

[rjvbb]

Hello,

This is a question about building an optimised custom kernel, hopefully this is the right place.

Currently mainly an LMDE user, I've been testing Kubuntu 14.04, mostly because it comes with KDE 4.13 . I must say I've been impressed (apart from a UI regression in SystemSettings/Displays, but that's got nothing to do with Kubuntu). Despite the fact that I installed to an external USB drive (btrfs), everything feels snappier than under LMDE.

The fact I'm running on an Acer Aspire AO722 netbook (AMD C60 CPU) with LMDE on a 2.5" internal HDD formatted under ZFS probably explains part of Kubuntu's perceived "snappierness": neither the internal HDD nor ZFS are speed daemons.

To quantify things, I ran subsets of the Phoronix netbook and linux-system benchmarks, and was surprised to see that LMDE was actually the faster in all benchmarks not dependent on disk I/O. On LMDE, I use a custom-built 3.12 kernel obtained from the Sabayon distribution, optimised for the C60 (-march=amdfam10 -O3 -ftracer) and with build options chosen to optimise performance according to my understanding (notably a 1000Hz clock and the cfq scheduler).

So I grabbed the 3.13 kernel sources using apt-get and tweaked the configuration as identically as possible, and did the benchmark again.

The result is a bit of a mixed bag; there's 1 test on which "my" kernel gives slower performance, for the rest the result is either (too) close to the stock system or, in a few tests, close to my 3.12 LMDE system.

Any suggestions how to configure an optimised kernel that is more likely to give a more consistent performance benefit? I'm not looking to split hairs, but OTOH every gain is welcome on such a low-end system (that for the rest runs KDE surprisingly well).
I should add that for the 3.12 kernel I simply tweaked the compiler flags in the Makefile to get amdfam10 specific code; with the 3.13 kernel I had to repurpose the flags for the K8 preselect, which may have given me additional settings that are suboptimum for the C60.
(Sadly it takes over 6h to build a new set of kernel packages with make-kpkg, and over 3h for the pts/netbook test so I cannot really afford a lot of trial and error).

[Jimmy.P]

Why not try Con Kolivas scheduler on the kernel see this.
Some say his patches are really good I never tried them my self becasue I'm more than happy with the kernel that comes with Kubuntu.

Also Arch Linux has a good wiki page describing some options...

[rjvbb]

You mean to say you are doing the compile on the netbook??

Yep. I haven't managed (yet) to build a cross compiling gcc 4.8.2 on OS X, so I can only use distcc with clang for the time being ... and that doesn't work for building the kernel.

[bendy]

I have to say (as a former gentoo user) that you can waste a lot of your life trying to compile your own kernel. You are highly unlikely to ever make a noticeable difference in normal desktop usage by messing with kernel settings and compiler options.

The only thing that may (and I stress the word may) make a difference is patching in newer hardware drivers of maybe a different scheduler like the Con Kolivas BFS scheduler above. Even then the benefits are usually minimal and the risk of breakage is high.

That said, if you want to do it for fun, or as an educational thing, then go ahead. But then you might as well go the whole hog and run gentoo....

[rjvbb]

I know, it's also my experience that most of the time, gains obtained through compiler flags are negligible, unless it's some form of -O vs. no optimisation at all, auto-vectorisation (on very specific code it can make a huge difference) or -mdynamic-no-pic on OS X. Then again, every bit of gain can count in lowlevel components that are used by just about any piece of software, and from what I've seen -march=amdfam10 does give a consistent benefit on my netbook vs. generic x86_64 code generation (though I never tried with -mno-sse -mno-avx as in the kernel build).

Or take Gentoo based Sabayon, very pretty!
A bit of a mix between compiling and pre compiled modules.

I've tried Sabayon, and if I had to opt for a gentoo-based distro it'd be that. It's a bit too bleeding-edge for me though, and while I don't mind spending some time from time to time to figure out how to do an optimised build, I also don't want to spend more time keeping my system uptodate than actually using it (I wouldn't want to know how long it'd take to build gcc or clang on this netbook!). Also, it's too much of a hassle to get certain apps to install, among which Google Chrome.

BTW: here's a comparison including my LMDE setup and the 3.13.9 kernel with CK patches and built with -O3 -march=amdfam10:

http://openbenchmarking.org/result/1...SO-1405052SO01

I'm beginning to think I ought to see if my custom 3.12 kernel installs under Kubuntu 14.04 ... maybe it's simply the 3.13 kernel that is slower on certain operations than the 3.12 kernel was.

[rjvbb]

I have to say (as a former gentoo user) that you can waste a lot of your life trying to compile your own kernel. You are highly unlikely to ever make a noticeable difference in normal desktop usage by messing with kernel settings and compiler options.

BTW - does the same apply to libc?

[bendy]

BTW - does the same apply to libc?

This partly depends on whether you are running 32 or 64 bit. Since there are not many generational differences between the various 64 bit processors, there is very little to be gained with compiler optimisations. If you are running 32 bit, then you might get a small benefit by compiling for i686 instead of i486. I haven't looked but I expect there are guidelines somewhere for standard compiler flags for creating debian and ubuntu binaries.

If you are interested in this stuff then I do suggest giving gentoo a go. You will give up a weekend getting it installed, but then you can see for yourself. Gentoo's forums are full of stuff about compiler and link time optimisations.

From my experience, Gentoo can give you a very quick system, but more of this is down to not running services by default that you don't need, than the relatively small benefit of compiler optimisations. And you spend a lot of time at the command line learning about linux......