Kernel image size
in [Embedded]
|
Prev: Suggested features for CASE to protect shared stores againstconflicting accesses
Next: New Microchip PIC32 Microcontrollers have Lots of Everything (2 CAN 2.0b, Ethernet, lots more)
From: Tim Wescott on 21 Nov 2009 13:57 On Fri, 20 Nov 2009 18:10:06 -0600, Nobby Anderson wrote: > I've recently upgraded a ppc405 build for a Virtex 4 device from kernel > 2.6.15 (arch/ppc) to 2.6.31 (arch/powerpc) and the size of the image has > increased from about 900k to 1.4M. As far as I can tell I've pretty > much the same config options set. The 2.6.15 kernel was straight from > the kernel mainline with some xilinx drivers hacked in, the .31 is > straight from git.xilinx.com with nothing additional hacked in but does > use for example the lltemac driver. > > Is that the sort of size increase I should expect, or is it likely I'm > missing something? It's nearly a 50% increase, which seems excessive! > > Nobby I _think_ that the (Linux) kernel build, by default, includes drivers for every known device that hes ever been plugged into a Linux machine, including the kitchen sink if it happens to have a USB port (but there's also a driver for kitchen sinks that use legacy parallel ports, and two different flavors of serial). Cutting all that out should keep the kernel size down. -- www.wescottdesign.com
From: Nobby Anderson on 21 Nov 2009 16:18
Nobody <nobody(a)nowhere.com> wrote: > On Fri, 20 Nov 2009 18:10:06 -0600, Nobby Anderson wrote: > >> I've recently upgraded a ppc405 build for a Virtex 4 device from kernel 2.6.15 >> (arch/ppc) to 2.6.31 (arch/powerpc) and the size of the image has increased >> from about 900k to 1.4M. As far as I can tell I've pretty much the same >> config options set. The 2.6.15 kernel was straight from the kernel mainline >> with some xilinx drivers hacked in, the .31 is straight from git.xilinx.com >> with nothing additional hacked in but does use for example the lltemac >> driver. >> >> Is that the sort of size increase I should expect, or is it likely I'm >> missing something? It's nearly a 50% increase, which seems excessive! > > A lot has happened between those two: > > 2.6.15 03-Jan-2006 > 2.6.15.7 28-Mar-2006 > ... > 2.6.31 09-Sep-2009 > 2.6.31.6 10-Nov-2009 > > Newer kernels occasionally get new features which are enabled by default, > and would need to be explicitly disabled. > > Individual drivers often have tables of known devices, and workarounds > for broken hardware. The size of both tends to increase over time. > > Compilation options can make a lot of difference. An kernel built for > embedded use probably won't use the default switches. > > If you're building these kernels from source, you can examine the number > and size of the object files which are built. More files tends to indicate > more features (drivers, modules), consistently larger files would indicate > compilation switches, inconsistently larger files would indicate specific > components acquiring new features. > Thanks to everybody who replied. I did eventually get the size down to near the old one by severely trimming out lots of options - as Nobody said there are a bunch of new things that are enabled by default. I'm not sure I know what made the biggest difference but the filesystem drivers had a marked effect - I didn't have any filesystems enabled that I don't need, but there seem to be a bunch of new options for the ext2-class of filesystems that make for quite a hefty kernel. I did find this web page which might be of some use to somebody: http://elinux.org/Kernel_Size_Tuning_Guide which introduced me to the aptly-named bloat-o-meter in the scripts directory in the kernel sources! Cheers, Nobby |