Kernel configuration options

[Bernardo Innocenti]

John Richard Moser wrote:
> I'm not sure about some of the kernel configuration options.  A few 
> minor things stick out in my mind; I don't know the rationale behind 
> some of these things and am curious about developer decisions and 
> thoughts on how to build the kernel.
> 
>   * CONFIG_NO_HZ + CONFIG_HZ=100?
>   * SLAB vs SLUB
>   * Some debugging stuff
>   * More debugging stuff
>   * Building stuff as modules

Please, build a kernel with the changes you consider useful,
and make it available somewhere, along with your proposed
config patch.  Please make sure that the resulting kernel
also still works on QEMU and VMware.

Extra bonus points if you can give hard numbers on memory
saving and performance gains.

As a super-quick-and-dirty test, note that /home/olpc/.boot_time
records the time it takes to get from kernel startup to the
X session.  We can expect that time to be slighly influenced
by your improvements because booting exercises several kernel
subsystems, including vfs, slab, forks and mmaps.


> First off I noticed CONFIG_NO_HZ=y and CONFIG_HZ=100; is this a quirk of 
> the kernel's general configuration?  As I understand, these options 
> should be mutually exclusive because CONFIG_HZ is a parameter of a 
> scheduler using a different methodology than CONFIG_NO_HZ...

Probably a (harmless) leftover of editing the .config manually.


> Another thing is I noticed CONFIG_SLAB=y, but the SLUB allocator is 
> supposed to be a faster generic replacement for SLAB.[1]  Is there a 
> reason the XO doesn't use it?

Don't expect too much out of it:
   http://lwn.net/Articles/261868/

But I still think we should try it and maybe use it.


> I'm also noticing some things like KALLSYMS and BUG(), BSD process 
> accounting, and the like.  KALLSYMS, BUG(), and printk() are useful; on 
> a true embedded device I'd say remove 'em but I can't justify it here... 
> BSD process accounting and auditd support though?

I'd keep the debug symbols (which shouldn't cost any memory
at runtime).


> In the same line, a lot of debugging options are in use.  I'm using 
> Build 653, I guess it may be a developer's build and thus there's a lot 
> of debugging stuff; but in the final should things like CONFIG_PROFILING 
> , CONFIG_KPROBES, CONFIG_DEBUG_FS, CONFIG_UNUSED_SYMBOLS, 
> CONFIG_SCHEDSTATS, CONFIG_TIMER_STATS, CONFIG_DEBUG_PREEMPT, 
> CONFIG_DEBUG_SPINLOCK ... be removed?

I side with M.Edward on keeping oprofile support, which does
not slowdown the system and can be built as a module.


> Finally, I'm noticing a lot of stuff can be built as modules, but is 
> built in.

Go for it!  But please note that we're using a weird initrd
that doesn't contain modules (or maybe does, but cannot easily
be regenerated along with the kernel).

Because of this, I think all the modules required for booting
off jffs2 and ext3 need to be linked in :-(

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/