Linux kernel/Image Size: Difference between revisions
(→Design) |
(→Vision) |
||
(3 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
== Vision == | == Vision == | ||
Reduce the flash and memory footprint of the linux-yocto generated kernel to boot with 8MB of memory and allow for a minimal image in under 8MB of flash on a reasonably fully featured target board, such as the Intel n450 Embedded Development board. The uncompressed kernel image should come in around 1.5MB. Changes to the kernel shall not impact POSIX compliance. | Reduce the flash and memory footprint of the linux-yocto generated kernel to boot with 8MB of memory and allow for a minimal image in under 8MB of flash on a reasonably fully featured target board, such as the Intel n450 Embedded Development board. The uncompressed kernel image should come in around 1.5MB. Changes to the kernel shall not impact POSIX compliance. In addition to an example small BSP, a document shall be published describing how to apply the work done here to an arbitrary BSP. | ||
This project is focused on the kernel image. A related project, the goal of which is to reduce the size of the entire image including the root filesystem, is documented as [[Minimal_Image]]. | |||
== Design == | == Design == | ||
The majority of the work here will center around CONFIG options. There is a start of a kernel type variant already in the linux-yocto tree, called | The majority of the work here will center around CONFIG options. There is a start of a kernel type variant already in the linux-yocto tree, called <code>small</code> which modifies the CONFIG for a smaller image. The output of this effort will mostly modify that mechanism. Major optional parameters, like disabling the block layer perhaps, will be created as peers to the <code>small</code> mechanism. These can be enabled in the recipe itself via: | ||
<pre> | <pre> | ||
KERNEL_FEATURES += "small noblock" | KERNEL_FEATURES += "small noblock" | ||
Line 10: | Line 12: | ||
Note that <code>small</code> will not address hardware configurations, but will instead address kernel features (such as tracing, networking, filesystems, IO schedulers, etc.) and kernel build options (printk, hash table sizes, etc.). Any hardware enabling must be done the BSP. BSPs may provide <code>small</code> variants as well to disable hardware features. In keeping with the goals of the [/Linux_Kernel/Boot_Time:Boot Time] effort, the kernel image must have all required hardware support for boot built-in. | Note that <code>small</code> will not address hardware configurations, but will instead address kernel features (such as tracing, networking, filesystems, IO schedulers, etc.) and kernel build options (printk, hash table sizes, etc.). Any hardware enabling must be done the BSP. BSPs may provide <code>small</code> variants as well to disable hardware features. In keeping with the goals of the [/Linux_Kernel/Boot_Time:Boot Time] effort, the kernel image must have all required hardware support for boot built-in. | ||
The approach will be to minimize the image as far as possible with existing infrastructure without creating very specialized hacks that must be continually maintained outside of mainline. If it turns out that we can make significant improvements to the sources or the configuration of the kernel to reduce image size, that development will be performed upstream-first, in the usual fashion. An audit of linux-tiny will determine if there are patches remaining there that we should help get included upstream. | The approach will be to minimize the image as far as possible with existing infrastructure without creating very specialized hacks that must be continually maintained outside of mainline. If it turns out that we can make significant improvements to the sources or the configuration of the kernel to reduce image size, that development will be performed upstream-first, in the usual fashion. As a rule of thumb, new configuration options must save more than 4k to be worth the added infrastructure. An audit of linux-tiny will determine if there are patches remaining there that we should help get included upstream. | ||
Initial development and prototyping will be completed using the qemux86 machine. Once a minimal general purpose config has been identified, further refinement will be done on the n450 machine. Finally, the general purpose | Initial development and prototyping will be completed using the qemux86 machine. Once a minimal general purpose config has been identified, further refinement will be done on the n450 machine. Finally, the general purpose <code>small</code> variant should be demonstrated to function on each of the four platforms defined in meta-yocto. Additionally, each of the machines defined in the meta-intel layer will be verified. Support for additional boards will require additional resources from interested parties. | ||
The links listed under Resources provide a good set of tasks to get started with as well as some background context. After working through that, a second round of image size reduction may need to be planned. | The links listed under Resources provide a good set of tasks to get started with as well as some background context. After working through that, a second round of image size reduction may need to be planned. |
Latest revision as of 21:53, 27 June 2011
Vision
Reduce the flash and memory footprint of the linux-yocto generated kernel to boot with 8MB of memory and allow for a minimal image in under 8MB of flash on a reasonably fully featured target board, such as the Intel n450 Embedded Development board. The uncompressed kernel image should come in around 1.5MB. Changes to the kernel shall not impact POSIX compliance. In addition to an example small BSP, a document shall be published describing how to apply the work done here to an arbitrary BSP.
This project is focused on the kernel image. A related project, the goal of which is to reduce the size of the entire image including the root filesystem, is documented as Minimal_Image.
Design
The majority of the work here will center around CONFIG options. There is a start of a kernel type variant already in the linux-yocto tree, called small
which modifies the CONFIG for a smaller image. The output of this effort will mostly modify that mechanism. Major optional parameters, like disabling the block layer perhaps, will be created as peers to the small
mechanism. These can be enabled in the recipe itself via:
KERNEL_FEATURES += "small noblock"
Note that small
will not address hardware configurations, but will instead address kernel features (such as tracing, networking, filesystems, IO schedulers, etc.) and kernel build options (printk, hash table sizes, etc.). Any hardware enabling must be done the BSP. BSPs may provide small
variants as well to disable hardware features. In keeping with the goals of the [/Linux_Kernel/Boot_Time:Boot Time] effort, the kernel image must have all required hardware support for boot built-in.
The approach will be to minimize the image as far as possible with existing infrastructure without creating very specialized hacks that must be continually maintained outside of mainline. If it turns out that we can make significant improvements to the sources or the configuration of the kernel to reduce image size, that development will be performed upstream-first, in the usual fashion. As a rule of thumb, new configuration options must save more than 4k to be worth the added infrastructure. An audit of linux-tiny will determine if there are patches remaining there that we should help get included upstream.
Initial development and prototyping will be completed using the qemux86 machine. Once a minimal general purpose config has been identified, further refinement will be done on the n450 machine. Finally, the general purpose small
variant should be demonstrated to function on each of the four platforms defined in meta-yocto. Additionally, each of the machines defined in the meta-intel layer will be verified. Support for additional boards will require additional resources from interested parties.
The links listed under Resources provide a good set of tasks to get started with as well as some background context. After working through that, a second round of image size reduction may need to be planned.
Next Steps
- Start with allnoconfig and get a minimal config booting on qemux86
- Determine the delta between this config and the yocto/standard config
- Work this delta into the "small" variant
- Modify this config to allow the n450 to boot
- Determine ways to minimize the image for the n450
- Create optional small variants
- Possibly M3 items
- Verify small variant works on all four meta-yocto defined machines
- Verify small variant works on all meta-intel defined machines
Resources
- http://elinux.org/Kernel_Size_Tuning_Guide
- http://elinux.org/Kernel_Size_Tuning_Guide_Config_Option_Impact
- http://elinux.org/System_Size
- http://elinux.org/Linux_Tiny
Results
Initial qemux86 (2163461ec94528ecf046a04edc5db3d2dd3a6b8b)
$ ls -la arch/x86/boot/bzImage -rw-rw-r-- 1 dvhart dvhart 4111664 2011-06-22 16:48 arch/x86/boot/bzImage $ ls -la vmlinux -rwxrwxr-x 1 dvhart dvhart 143686262 2011-06-22 16:47 vmlinux $ size vmlinux text data bss dec hex filename 7261405 779724 1603032 9644161 932881 vmlinux