Kernel configuration options

[John Richard Moser]

Bernardo Innocenti wrote:
> John Richard Moser wrote:
> 
>>> 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?
> 
> Yes, but it doesn't take that much.  It's probably just a
> pci IDE controller and the vesafb.
> 
> 
>> 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?)
> 
> Yes, you do need a developer key.  What is an smth?
> 

something

> Rebuilding the kernel RPM is less than trivial.  You may
> prefer just building the kernel and then copying it on the
> target with a stupid script like this one:
> 

> tar -C $stagedir -czf - . | ssh root@$dest tar -C $destdir -xvzf -

So glad right now that ssh doesn't allow blank password log-in.

So very glad.

> 
> 
>>> Extra bonus points if you can give hard numbers on memory
>>> saving and performance gains.
>>>
>> Black art ;)
> 
> Well, "size vmlinux" may be a lower bound approximation
> for the memory saving.  Combined with some /proc/slabinfo
> magic you'd get closer.
> 
> As you say, performance is hard to measure.  Shell scripts
> tend to be good kernel benchmarks because they create lots
> of processes, file descriptors, and do a lot of I/O.
> 

Point taken.

>>> 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...
> 
> Not on the Geode: we don't have MTRRs, so I guess the kernel
> is being mapped by 4KB pages.
> 

Remove hugetlbfs then.

> But anyway, aren't the symbols in a separate ELF section?
> So probably they end up in the vmlinuz binary too, but
> I've not checked.
> 
> 
>>> 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.
> 
> Hmmm, people may like to boot off USB and SD, wouldn't they?
> We're talking about a very small saving anyway...

Would you boot off the kernel on the flash and then load the system from 
the USB or SD, or use a kernel on the SD card?

> 
> 
>> 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.
> 
> We still have plenty of places where we could recover several
> *seconds* of boot time with just minor changes.  So I don't think
> we should worry too much about module load time, which is probably
> very fast.
> 
> In my experience, module load time is usually dominated by the work
> being done in the init function, which sometimes involves sleeping
> or performing slow I/O (i2c, serial, USB...).  This time would also
> be spent in the monolithic kernel.
> 

So this raises the question:  By parallelizing boot and using an 
event-driven init system like Ubuntu's Upstart, could you actually get 
to running application code before loading the modules; and then set up 
all the hardware while more CPU-bound parts of the boot process run? 
Sort of bring up the system while all the devices are being initialized, 
just as long as graphics + keyboard + mouse are up for X to start when 
it gets there.

> 
>> 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.
> 
> I agree with you.
> 
> 
>> Really I like a tiny core kernel and a bunch of modules but as
>> I said, increases the time needed to boot.
> 
> I once again agree with you, except that I don't think
> the load time increase will be problematic on the XO.
> 

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