kernel defconfig, debugging, preemption, and very noticeable speedups/ debugging

Gennady Kupava gb at
Fri Jan 8 11:39:49 CET 2010

hi, all

ok, all this proposed changes seem too much to digest in one go, let's
discuss them individually.

let's talk about debugging.

i am not true kernel hacker, but here is my thoughts, i'll be glad to be

i see no reason why debugging features should be enabled for anyone
expect kernel developers, and kernel developers i think, should only
enable features directly related to things they are doing. for example
where is comletely no point to have such things like spinlocks, mutexes,
preemtion, irq, file system, sound, nand and other for which i cann't
guess that they are doing. do .config|grep DEBUG to see what's enabled.
many debugging features add huge overhead, and i don't understand how
they are helping anyone.

tests i did confirm that debugging overhead is huge, and i think this is
real thing which makes our device 'slow' - nothing more. so, i propose
to turn that off


В Чтв, 07/10/2010 в 01:22 +0400, Gennady Kupava пишет:
> hi all, next bunch of kernel config changes.
> i did series of tests with lmbench disable next part of performance-wise
> options in kernel config. I archived very fast result. For example, top
> average CPU usage were dropped down from 3.2% with default config kernel
> to 1.6% average.
> test environment:
> debian on sd, andy-tracking kernel with default config
> (gta02_moredrivers_defconfig) for gta02 + plus one feature changed. all
> tests were run several times
> Features changed as in summary report:
> 1. defconfig - default config
> 2. nodebug - debugging off : all except "Enable dynamic printk() call
> support" and "timing info"
> 3. speed - use -O2 optimization instead of -Os
> 4. nopreempt - disable preemtion (CONFIG_PREEMPT)
> test results:
> see
> comments:
> file operations should be ignored, variuos memcpys and cache speeds can
> be used to mae sure that tests are comparable and system is ok.
> iterpretation:
> 1. debug impact is huge - 10x in open/close test, 13% on select, 10x on
> signal hadling, 2x on exec, 2x on fork, 1,8x on context switches. 50% on
> pipe latency, 30% on local TCP, 30% on pipes. system feel much faster.
> 2. preemption disable: smaller scale speedups, but also seem very
> noticeable.
> 3. optimising for speed have some impact in different areas, + and -, 0
> in total, but much things were not tested.
> comclusion:
> so i propose to:
> 1) disable debugging for sure.
> 2) disable preemtion.
> 3) disable optimization for speed.
> gennady

More information about the openmoko-kernel mailing list