Kernel configuration options

[John Richard Moser]

Bernardo Innocenti wrote:
> 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.
> 

The base hardware drivers built in supports qemu and vmware?

Looks like I gotta read up on the wiki about how to rebuild the kernels 
(again).  It seems I can alter Grub to do what I want afterwards though. 
  (Do I need a developer's key or smth?)

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

Black art ;)

> 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.
> 

Interesting!  I didn't know this.  Boot chart was pulled out for 
something else that I don't know how to use yet as well.

> 
>> 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/
> 

Point taken.

> 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).

Possibly not.  The kernel runs inside one giant huge page doesn't it? 
4MiB read-write-execute...

> 
> 
>> 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 :-(
> 

I think you can omit booting off ext3 for the final product.

There is load-time consideration to be made about loading everything as 
modules (camera, USB, mouse, all of networking, sound, etc) and leaving 
the essentials (flash, display, keyboard, jffs2).  Even if you leave 
networking and all the 100%-always-loaded modules compiled in, however, 
there's no need for things like 30 types of file systems.

I'd personally leave out ipv4 and ipv6 and just load them at boot time; 
I'd rather not have ipv6 loaded right now, and ipv6 infrastructures 
should run without ipv4 (some apps will probably complain about no 
127.0.0.1...); but this is just nitpicking.  Really I like a tiny core 
kernel and a bunch of modules but as I said, increases the time needed 
to boot.


-- 
Bring back the Firefox plushy!
http://digg.com/linux_unix/Is_the_Firefox_plush_gone_for_good
https://bugzilla.mozilla.org/show_bug.cgi?id=322367