Difference between revisions of "System Size"

From eLinux.org
Jump to: navigation, search
(reorganice content)
(removing traces of old address)
(26 intermediate revisions by 6 users not shown)
Line 1: Line 1:
 
Here are some links to information and projects related to Linux system size.
 
Here are some links to information and projects related to Linux system size.
  
== Documentation on reducing kernel size ==
 
[[Kernel Size Tuning Guide]] is a draft of a document on the subject of measuring and reducing the size of the Linux kernel
 
  
* [[Kernel Size Tuning Guide]]
 
* http://www.halobates.de/memorywaste.pdf - Great paper by Andi Kleen, of SUSE Labs, about dynamic memory usage of Linux systems
 
  
 
== Technologies for decreasing system size ==
 
== Technologies for decreasing system size ==
 
=== Kernel size reduction ===
 
=== Kernel size reduction ===
 +
==== Configuration Options ====
 +
* [[Kernel Size Tuning Guide]] - document about measuring kernel size and configuring the kernel for smallest size
  
 
==== The Linux-tiny patchset ====
 
==== The Linux-tiny patchset ====
Line 20: Line 18:
 
The first option is -Os which is already in the tiny kernel patch.
 
The first option is -Os which is already in the tiny kernel patch.
  
The second option is new in gcc 3.4, -funit-at-a-time. This apparently makes gcc
+
Since version 3.4, gcc offered a -funit-at-a-time option.
do a much better job of inlining and dead code removal.  It reduces the
+
This apparently made gcc do a much better job of inlining and dead code removal,
size of both text and data. It depends on another inlining patch that I
+
reducing the size of both text and data. It depended on another inlining patch.
think is in the tiny kernel patch (maybe same idea but different details).
+
According to gcc's manual, this option no longer does anything.
  
The third option, -mregparm=3, seems to be x86 specific, it instructs the
+
The -fwhole-program --combine option set is equivalent to grouping all source files
 +
and making all variables static. These options are still supported by gcc, but not longer offered in BusyBox
 +
configuration options. What happened?
 +
 
 +
Another option, -mregparm=3, seems to be x86 specific, it instructs the
 
compiler to use registers for the first three function arguments. by John Rigby
 
compiler to use registers for the first three function arguments. by John Rigby
 +
 +
See [http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html] for all
 +
available optimization switches.
 +
See [[Compiler_Optimization]] for more details on effects of optimization options.
 +
 +
==== Section garbage collection patchset ====
 +
These [http://busybox.net/~vda/k-sections/ patches] can shrink kernel size by ~10% by improving dead code/data elimination at link time. They are being pushed to mainline. Due to a linker [https://bugzilla.redhat.com/show_bug.cgi?id=621742 bug], their acceptance depends on a newer, fixed linker (will be in binutils-2.21). Good news are that the bug affects only certain architectures (parisc), so the patches are usable even with "old" linker.
 +
 +
==== Runtime size of kernel ====
 +
Often, the focus of memory size reduction for the kernel is on the size of the
 +
statically compiled image for the kernel.  However, the kernel also allocates
 +
memory dynamically when it runs.  On loading, the kernel creates several tables
 +
for things like network and file system structures.
 +
 +
Here is a table showing different kernel hash tables, and their approximate
 +
size for a 2.6 kernel.  (Table taken from page 25 of
 +
http://logfs.org/~joern/data_structures.pdf )
 +
 +
{| border="1" cellspacing="0" cellpadding="5" align="center"
 +
!Hash Table        !!memory < 512MiB RAM !! memory >=512MiB RAM
 +
|-
 +
!                  !!32b/64b      !!32b/64b
 +
|-
 +
|TCP established    ||96k/192k      ||384k/768k
 +
|-
 +
|TCP bind          || 64k/128k    || 256k/512k
 +
|-
 +
|IP route cache    || 128k/256k    ||  512k/1M
 +
|-
 +
|Inode-cache        ||  64k/128k    ||  64k/128k
 +
|-
 +
|Dentry cache      ||  32k/64k    ||    32k/64k
 +
|-
 +
||Total            ||  384k/768k  || 1248k/2496k
 +
|}
 +
 +
===== kernel stack size =====
 +
There used to be a configuration option for reducing the size of the kernel stack for each process to 4K.
 +
By default (as of 2011), the default kernel stack size is 8K.  If you have a lot of processes, then
 +
using 4K stacks can reduce the kernel stack usage.
 +
 +
Some notes about this are at: [[Kernel Small Stacks]]
  
 
=== File system compression ===
 
=== File system compression ===
 
For read-only data, it is useful to utilize a compressed file system.
 
For read-only data, it is useful to utilize a compressed file system.
 
The following are used heavily in embedded systems:
 
The following are used heavily in embedded systems:
* JFFS2
+
* Cramfs and SquashFS, for block storage.
* Cramfs
+
* JFFS2 and its successor UBIFS, for flash (MTD) storage.
* SquashFS
+
 
 +
Note that Cramfs and Squashfs, due to their "write-only-once" nature, can also be used on MTD storage.
  
 
See the [[File Systems]] page for more information.
 
See the [[File Systems]] page for more information.
 +
 +
=== Shrinking your application ===
 +
==== Compiler options for program size ====
 +
You can use "gcc -Os" to optimize for size.
 +
 +
==== Stripping your program ====
 +
You can use the 'strip' command to eliminate unneeded symbols from your application.
 +
The 'strip' command should be included with your toolchain, and may be architecture-specific.
 +
(I.e. you may need to run it with a toolchain prefix, like "arm-linux-strip")
 +
 +
Note that this makes debugging your application more difficult, because the debug
 +
symbols are no longer available.
 +
 +
By default, strip just removes debug symbols.  You can remove everything but the essential
 +
symbols used for dynamic linking. To get the highest savings, use "strip --strip-unneeded <app>"
 +
 +
This can save a lot of space, especially if debug symbols were included in the build.
 +
 +
$ gcc -g hello.c -o hello
 +
$ ls -l hello
 +
-rwxrwxr-x 1 tbird tbird 6143 2009-02-10 09:43 hello
 +
$ strip hello
 +
$ ls -l hello
 +
-rwxrwxr-x 1 tbird tbird 3228 2009-02-10 09:43 hello
 +
$ strip --strip-unneeded hello
 +
$ ls -l hello
 +
-rwxrwxr-x 1 tbird tbird 3228 2009-02-10 09:43 hello
 +
 +
Now, compiles without debug symbols to start with:
 +
 +
$ gcc hello.c -o hello
 +
$ ls -l hello
 +
-rwxrwxr-x 1 tbird tbird 4903 2009-02-10 09:45 hello
 +
$ strip hello
 +
$ ls -l hello
 +
-rwxrwxr-x 1 tbird tbird 3228 2009-02-10 09:45 hello
 +
 +
You can strip both executables as well as shared libraries.
 +
 +
There is a "super-strip" utility, which removes additional material from an ELF executable program (which 'strip'
 +
usually misses).  It is available at: http://muppetlabs.com/~breadbox/software/elfkickers.html
 +
''This program appears to be obsolete now.  I couldn't get it to compile on Fedora 8''.
 +
 +
Some information about stripping individual sections by hand, using the -R command is available at: http://reverse.lostrealm.com/protect/strip.html
 +
 +
==== Hand-optimizing programs, for size ====
 +
If you are very intent on creating small binaries, you can use some techniques to manually
 +
create the smallest Linux executables possible.
 +
 +
See [http://muppetlabs.com/~breadbox/software/tiny/teensy.html A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux]
  
 
=== Library savings ===
 
=== Library savings ===
Line 46: Line 141:
 
* [http://www.fefe.de/dietlibc/ dietlibc] - another library to produce very small statically compiled executables.
 
* [http://www.fefe.de/dietlibc/ dietlibc] - another library to produce very small statically compiled executables.
 
* [http://www.kernel.org/pub/linux/libs/klibc/ klibc] - very small library for use in init ram filesystems
 
* [http://www.kernel.org/pub/linux/libs/klibc/ klibc] - very small library for use in init ram filesystems
 +
* [http://www.eglibc.org/home eglibc] - a version of glibc designed for embedded systems. Reduced footprint is one of the design goals.
 
* Subset Libc Specification - CELF once considered the possibility of creating a subset libc specification.  Some companies have also examined the possibility of modularizing glibc, so that parts of it can be made configurable.  Preliminary research indicates that this could be a very difficult thing, since glibc has very messy function interdependencies.
 
* Subset Libc Specification - CELF once considered the possibility of creating a subset libc specification.  Some companies have also examined the possibility of modularizing glibc, so that parts of it can be made configurable.  Preliminary research indicates that this could be a very difficult thing, since glibc has very messy function interdependencies.
  
Line 85: Line 181:
 
==== Application XIP ====
 
==== Application XIP ====
 
By executing applications in-place from flash, it is possible to save RAM space.
 
By executing applications in-place from flash, it is possible to save RAM space.
*see ApplicationXIP
+
*see [[Application XIP]]
  
 
==== Data Read In Place (DRIP) ====
 
==== Data Read In Place (DRIP) ====
Line 94: Line 190:
 
== Size measurement tools and techniques ==
 
== Size measurement tools and techniques ==
 
=== Kernel size measurement data ===
 
=== Kernel size measurement data ===
* [http://testlab.celinuxforum.org/bloatwatch/index.cgi Bloatwatch] - a kernel size regression analysis tool.
+
* [http://www.selenic.com/bloatwatch/ Bloatwatch] - a kernel size regression analysis tool.
** Bloatwatch provides a great amount of detail, and the ability to compare the size of kernel versions over time. The range of kernels covered is from 2.6.12-rc2 to 2.6.17-rc1. Unfortunately, the system to
+
** Bloatwatch provides a great amount of detail, and the ability to compare the size of kernel versions over time.
collect kernels and test them broke about the time of 2.6.17, and the system stopped operating at that time.
+
** If you have interest in reviving this tool to make it operational again, please contact [[User:Tim Bird]].  [[CELF]] has some contract money earmarked for this project.
+
 
+
  
 
=== How to measure the kernel image size ===
 
=== How to measure the kernel image size ===
Line 143: Line 236:
  
 
Please see the [[Szwg Linux 26Data]] page for supporting data.
 
Please see the [[Szwg Linux 26Data]] page for supporting data.
 +
 +
* [[Size Tunables]]
  
 
=== GCC Code-Size Benchmarking ===
 
=== GCC Code-Size Benchmarking ===
Line 150: Line 245:
  
 
== Case Studies ==
 
== Case Studies ==
* Motorola reduction of system size (presumably for cell phones) using 2.4 Linux:  MotSizeReduction.ppt - this is a placeholder for this Powerpoint as it was too big to upload to the wiki. Email btraynor at gmail.com if you need it immediately.
+
* Motorola reduction of system size (presumably for cell phones) using 2.4 Linux:  MotSizeReduction.ppt - this is a placeholder for this Powerpoint as it was too big to upload to the wiki.
 +
 
 +
== Reduced-size distribution efforts ==
 +
Here are some projects aimed at building small-sized systems:
 +
* http://cgit.openembedded.org/meta-micro/
 +
** It's maintained by Phil Blundell. It appears pretty successful in reducing size of the resulting image whilst keeping the system fairly functional. It uses uClibc
 +
* [http://git.infradead.org/users/dvhart/meta-tiny.git Meta-tiny git repository]
 +
** Meta-tiny is an effort to build a small-footprint system using Yocto, by Darren Hart
 +
 
 +
meta-tiny is my experimental layer where I'm looking at what we can
 +
build with our existing sources and infrastructure. I've found that we
 +
can cut the image size to about 10% of core-image-minimal without
 +
changes to source code, but dropping a lot of functionality. We can get
 +
to something like 20% while still maintaining ipv4 networking.
 +
 
  
 
== Other Tidbits on System Size ==
 
== Other Tidbits on System Size ==
Line 162: Line 271:
  
 
See [http://groups.google.com/group/linux.kernel/msg/e1f9f579a946333e?hl=en& this post by Linus Torvalds]
 
See [http://groups.google.com/group/linux.kernel/msg/e1f9f579a946333e?hl=en& this post by Linus Torvalds]
 +
 +
=== Stripping down the filesystem of a desktop distribution ===
 +
Here is a good document with tips on how to strip out unneeded files from a desktop distribution.
 +
The example distribution used here is Linux From Scratch, but the tips should work with many
 +
distributions.
 +
 +
http://www.linuxfromscratch.org/hints/downloads/files/OLD/stripped-down.txt
 +
 +
=== Extremely-minimal systems ===
 +
This section lists various efforts to produce the absolute smallest system possible.
 +
 +
* Someone is running an old version of BSD on a small processor with only 128K (that's right 'K'!!) of RAM.
 +
** http://olimex.wordpress.com/2012/04/04/unix-on-pic32-meet-retrobsd-for-duinomite/
  
 
[[Category:System Size]]
 
[[Category:System Size]]

Revision as of 02:19, 17 December 2012

Here are some links to information and projects related to Linux system size.


Technologies for decreasing system size

Kernel size reduction

Configuration Options

The Linux-tiny patchset

  • The Linux Tiny patch set is a collection of patches which can be used to make the Linux kernel consume less space. The long-term goal of the Linux-tiny project is to mainline these patches. Several patches have been mainlined over the last few years, and work continues in this area.

Compiler options for reducing kernel size

An LWN article talks about three gcc options to shrink the kernel.

Shrinking the Kernel with GCC

The first option is -Os which is already in the tiny kernel patch.

Since version 3.4, gcc offered a -funit-at-a-time option. This apparently made gcc do a much better job of inlining and dead code removal, reducing the size of both text and data. It depended on another inlining patch. According to gcc's manual, this option no longer does anything.

The -fwhole-program --combine option set is equivalent to grouping all source files and making all variables static. These options are still supported by gcc, but not longer offered in BusyBox configuration options. What happened?

Another option, -mregparm=3, seems to be x86 specific, it instructs the compiler to use registers for the first three function arguments. by John Rigby

See [1] for all available optimization switches. See Compiler_Optimization for more details on effects of optimization options.

Section garbage collection patchset

These patches can shrink kernel size by ~10% by improving dead code/data elimination at link time. They are being pushed to mainline. Due to a linker bug, their acceptance depends on a newer, fixed linker (will be in binutils-2.21). Good news are that the bug affects only certain architectures (parisc), so the patches are usable even with "old" linker.

Runtime size of kernel

Often, the focus of memory size reduction for the kernel is on the size of the statically compiled image for the kernel. However, the kernel also allocates memory dynamically when it runs. On loading, the kernel creates several tables for things like network and file system structures.

Here is a table showing different kernel hash tables, and their approximate size for a 2.6 kernel. (Table taken from page 25 of http://logfs.org/~joern/data_structures.pdf )

Hash Table memory < 512MiB RAM memory >=512MiB RAM
32b/64b 32b/64b
TCP established 96k/192k 384k/768k
TCP bind 64k/128k 256k/512k
IP route cache 128k/256k 512k/1M
Inode-cache 64k/128k 64k/128k
Dentry cache 32k/64k 32k/64k
Total 384k/768k 1248k/2496k
kernel stack size

There used to be a configuration option for reducing the size of the kernel stack for each process to 4K. By default (as of 2011), the default kernel stack size is 8K. If you have a lot of processes, then using 4K stacks can reduce the kernel stack usage.

Some notes about this are at: Kernel Small Stacks

File system compression

For read-only data, it is useful to utilize a compressed file system. The following are used heavily in embedded systems:

  • Cramfs and SquashFS, for block storage.
  • JFFS2 and its successor UBIFS, for flash (MTD) storage.

Note that Cramfs and Squashfs, due to their "write-only-once" nature, can also be used on MTD storage.

See the File Systems page for more information.

Shrinking your application

Compiler options for program size

You can use "gcc -Os" to optimize for size.

Stripping your program

You can use the 'strip' command to eliminate unneeded symbols from your application. The 'strip' command should be included with your toolchain, and may be architecture-specific. (I.e. you may need to run it with a toolchain prefix, like "arm-linux-strip")

Note that this makes debugging your application more difficult, because the debug symbols are no longer available.

By default, strip just removes debug symbols. You can remove everything but the essential symbols used for dynamic linking. To get the highest savings, use "strip --strip-unneeded <app>"

This can save a lot of space, especially if debug symbols were included in the build.

$ gcc -g hello.c -o hello
$ ls -l hello
-rwxrwxr-x 1 tbird tbird 6143 2009-02-10 09:43 hello
$ strip hello
$ ls -l hello
-rwxrwxr-x 1 tbird tbird 3228 2009-02-10 09:43 hello
$ strip --strip-unneeded hello
$ ls -l hello
-rwxrwxr-x 1 tbird tbird 3228 2009-02-10 09:43 hello

Now, compiles without debug symbols to start with:

$ gcc hello.c -o hello
$ ls -l hello
-rwxrwxr-x 1 tbird tbird 4903 2009-02-10 09:45 hello
$ strip hello
$ ls -l hello
-rwxrwxr-x 1 tbird tbird 3228 2009-02-10 09:45 hello

You can strip both executables as well as shared libraries.

There is a "super-strip" utility, which removes additional material from an ELF executable program (which 'strip' usually misses). It is available at: http://muppetlabs.com/~breadbox/software/elfkickers.html This program appears to be obsolete now. I couldn't get it to compile on Fedora 8.

Some information about stripping individual sections by hand, using the -R command is available at: http://reverse.lostrealm.com/protect/strip.html

Hand-optimizing programs, for size

If you are very intent on creating small binaries, you can use some techniques to manually create the smallest Linux executables possible.

See A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux

Library savings

Use of a smaller libc

Glibc is the default C library used for Linux systems. Glibc is about 2 meg. in size. Other C libraries are also available for Linux, and they offer varying degrees of compatibility and size savings. In general, uClibc is considered a very good alternative to glibc, for systems where size is an issue.

  • uClibc - small footprint but complete C library
  • dietlibc - another library to produce very small statically compiled executables.
  • klibc - very small library for use in init ram filesystems
  • eglibc - a version of glibc designed for embedded systems. Reduced footprint is one of the design goals.
  • Subset Libc Specification - CELF once considered the possibility of creating a subset libc specification. Some companies have also examined the possibility of modularizing glibc, so that parts of it can be made configurable. Preliminary research indicates that this could be a very difficult thing, since glibc has very messy function interdependencies.

Static Linking

If your set of applications is small, sometimes it makes more sense to statically link your applications than to use shared libraries. Shared libraries by default include all symbols (functions and data structures) for the features a library provides. However, when you static link a program to a library, only the symbols that are actually referenced are linked in and included in the program.

Library reduction

It is possible to reduce the size of shared libraries, by eliminating unused symbols.

MontaVista released a tool for library optimization. This tool scans the entire file system, and can rebuild the shared libraries for the system, including only the symbols needed for the set of applications in the indicated file system.

Care needs to be taken with this approach, since it may make it difficult to use add-on programs or or do in-field upgrades (since symbols required by the new software may not be present in the optimized libraries). But for some fixed-function devices, this can reduce your library footprint dramatically.

See http://libraryopt.sourceforge.net/

Deferred Library Loading

It is possible to reduce the RAM runtime footprint for a product, by lazily loading shared libraries, and by breaking up library dependencies. Panasonic did some research into a process called Deferred Library Loading, which they presented at ELC 2007.

See the Deferred Dynamic Loading presentation.

Execute-in-place

You can save RAM memory by using some text or data directly from flash.

Kernel XIP

By executing the kernel in-place from flash, it is possible to save RAM space.

Application XIP

By executing applications in-place from flash, it is possible to save RAM space.

Data Read In Place (DRIP)

This is a technique for keeping data in flash, until it is written to, and then making a RAM page for it.

Size measurement tools and techniques

Kernel size measurement data

  • Bloatwatch - a kernel size regression analysis tool.
    • Bloatwatch provides a great amount of detail, and the ability to compare the size of kernel versions over time.

How to measure the kernel image size

  • to see the size of the major kernel sections (code and data):
size vmlinux */built-in.o
[tbird@crest ebony]$ size vmlinux */built-in.o
   text    data     bss     dec     hex filename
2921377  369712  132996 3424085  343f55 vmlinux
 764472   35692   22768  822932   c8e94 drivers/built-in.o
 918344   22364   36824  977532   eea7c fs/built-in.o
  18260    1868    1604   21732    54e4 init/built-in.o
  39960     864     224   41048    a058 ipc/built-in.o
 257292   14656   34516  306464   4ad20 kernel/built-in.o
  34728     156    2280   37164    912c lib/built-in.o
 182312    2704     736  185752   2d598 mm/built-in.o
 620864   20820   26676  668360   a32c8 net/built-in.o
   1912       0       0    1912     778 security/built-in.o
    133       0       0     133      85 usr/built-in.o
  • to see the size of the largest kernel symbols:
    • nm --size -r vmlinux
[tbird@crest ebony]$ nm --size -r vmlinux | head -10
00008000 b read_buffers
00004000 b __log_buf
00003100 B ide_hwifs
000024f8 T jffs2_garbage_collect_pass
00002418 T journal_commit_transaction
00002400 b futex_queues
000021a8 t jedec_probe_chip
00002000 b write_buf
00002000 D init_thread_union
00001e6c t tcp_ack

How to measure the memory usage at runtime

See Runtime Memory Measurement for a description of ways to measure runtime memory usage in Linux.

Also, see Accurate Memory Measurement for a description of techniques (and patches) which can be used to measure the runtime memory more accurately.

Linux size increase from 2.4 to 2.6

Linux increased in size by between 10% and 30% from version 2.4 to 2.6. This incremental growth in kernel size has been a big concern by forum members.

Please see the Szwg Linux 26Data page for supporting data.

GCC Code-Size Benchmarking

CSiBE is a code size benchmark for the GCC compiler. The primary purpose of CSiBE is to monitor the size of the code generated by GCC. In addition, compilation time and code performance measurements are also provided.

CSiBE

Case Studies

  • Motorola reduction of system size (presumably for cell phones) using 2.4 Linux: MotSizeReduction.ppt - this is a placeholder for this Powerpoint as it was too big to upload to the wiki.

Reduced-size distribution efforts

Here are some projects aimed at building small-sized systems:

meta-tiny is my experimental layer where I'm looking at what we can
build with our existing sources and infrastructure. I've found that we
can cut the image size to about 10% of core-image-minimal without
changes to source code, but dropping a lot of functionality. We can get
to something like 20% while still maintaining ipv4 networking.


Other Tidbits on System Size

Memory leak detection for the kernel

Catalin Marinas of ARM has been recently (as of 2.6.17?) been posting a memory leak detector for the Linux kernel. It may get mainlined in the future. Here's a link to the LKML discussions around it: http://lkml.org/lkml/2006/6/11/39

How System Size may affect performance

It has long been theorized that reducing system size could provide a performance benefit because it could reduce cache misses. There does not appear to be hard data to support this theory on Linux, but this has been discussed on the kernel mailing list.

See this post by Linus Torvalds

Stripping down the filesystem of a desktop distribution

Here is a good document with tips on how to strip out unneeded files from a desktop distribution. The example distribution used here is Linux From Scratch, but the tips should work with many distributions.

http://www.linuxfromscratch.org/hints/downloads/files/OLD/stripped-down.txt

Extremely-minimal systems

This section lists various efforts to produce the absolute smallest system possible.