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

Gennady Kupava gb at bsdmn.com
Sun Jan 10 08:06:18 CET 2010


В Вск, 10/01/2010 в 01:52 -0300, Werner Almesberger пишет:
> Paul Fertser wrote:
> > I suspect that the most useful debugging features (that should be in
> > kernels all users are using) add no overhead at all.
> 
> That's also my expectation. Therefore, I'm a bit surprised by the
> massive improvements reported.

I am really surprised that i have to spend so much time talking about
this issue, which seem very trivial for me. It's easy from my pov - if
you do spinlocks accounting - you'll get massive slowdown. if you start
debugging interrupts - you got slowdown. if you add symbols - you got 5x
memory consumption. you wish to add addtional check and debug preemption
- you'll get slowdown, if you wish to debug mutexes, you'll get
slowdown.

may be something is not so visible on desktops, but slower embedded
devices do not forgive such debugging on the side of user.

> 
> Now, it could well be that there are some debug options that look
> perfectly harmless (at least to me) but that have a high cost.
> 
> Another possibility would be that some options just produce a
> small increase of the amount of kernel messages printed. That in
> turn could, combined with the very inefficient scrolling to the
> kernel's frame, buffer cause significant effects in some tests.
> 
> Another possibility is that some systems may encounter a large
> number of slightly abnormal conditions that generate messages when
> debugging is enabled, while other systems are quiet. Thus, not all
> developers may experience the slowdown.

no. anyone seem expierence this, see reports in community ml. have you
tried to use the kernel without debugging?

> 
> So, something was found, but I think a bit more work is needed to
> identify what it really is. Identifying the costly debug options
> will also help to be aware of the performance impact if they are
> needed in the future.

it's hard to find 10% performance impact with testing individual
options, as they have stistical error, but few such 10% may provide
major slowdown and eventually run us out of cache.

> 
> I would agree that many debug options are indeed only useful when
> chasing a bug, but some also produce diagnostics useful for
> getting a first idea of what's happening. We would win little if
> users would normally run an extremely lean kernel but get asked to
> install some fat debug kernel each time they report a bug.

this is normal practice in whole world - to install debugging version if
you want to help with chasing bug. 

i checked debian kernel for versatile board and found that following
options are on:
CONFIG_USB_SERIAL_DEBUG=m
CONFIG_OCFS2_DEBUG_MASKLOG=y
CONFIG_DLM_DEBUG=y
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_KERNEL=y
CONFIG_SCHED_DEBUG=y
CONFIG_DEBUG_BUGVERBOSE=y

compare to our:
CONFIG_DEBUG_GPIO=y
CONFIG_SND_DEBUG=y
CONFIG_SND_PCM_XRUN_DEBUG=y
CONFIG_USB_S3C2410_DEBUG=y
CONFIG_REGULATOR_DEBUG=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SHIRQ=y
CONFIG_SCHED_DEBUG=y
CONFIG_DEBUG_PREEMPT=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_DEBUG_LOCKDEP=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_DEBUG_SG=y
CONFIG_DYNAMIC_PRINTK_DEBUG=y
CONFIG_DEBUG_ERRORS=y
CONFIG_DEBUG_S3C_UART=2

i propose more intellegent way - identify which features we really need
and why, and turn them on. embeeded device will not forgive you adding
much accaunting also, so things which can just be 'turned on because
overhead is negligible' on desktop are better to turn off on slower
embedded device imo.

i think only options really needed are options which allow backtrace. 

> 
> Related to this, it would be great if the GTA02 kernel's text
> console had Glamo-accelerated scrolling. A long time ago, I
> thought adding such a block move would be a nice late night
> project, but I failed to elicit even the slightest response from
> the Glamo. Some time later, Harald mentioned that he was giving it
> a try as well, but apparently without much success either. Maybe
> third time's lucky ?

having anything accelerted is good thing, but all this debug thing is
not related to glamo or speed of kernel messages. it's hard to describe
microtests speedup like context switches or file open/close with glamo,
no way to understand why cpu usage of running top decreased 2x - no
kernel messages are produced in process. please dont think that only
boot time is changed. forget glamo in this case, i think it's ok.

> By the way, Gennady, your mails may not reach some readers because
> they're dated way into the future (about 9 months ahead), which is
> something that normally identifies spam. And even for those who do
> see the mails, it messes up their mailbox order.

urghh. fixed. hope that this is only reason :)

gennady.




More information about the openmoko-kernel mailing list