Here are some links to information and projects related to Linux system size.
- 1 Technologies for decreasing system size
- 1.1 Kernel size reduction
- 1.2 File system compression
- 1.3 Library savings
- 1.4 Execute-in-place
- 2 Size measurement tools and techniques
- 3 Case Studies
- 4 Other Tidbits on System Size
Technologies for decreasing system size
Kernel size reduction
- Kernel Size Tuning Guide - document about measuring kernel size and configuring the kernel for smallest size
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.
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 do a much better job of inlining and dead code removal. It reduces the size of both text and data. It depends on another inlining patch that I think is in the tiny kernel patch (maybe same idea but different details).
The third option, -mregparm=3, seems to be x86 specific, it instructs the compiler to use registers for the first three function arguments. by John Rigby
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|
|IP route cache||128k/256k||512k/1M|
File system compression
For read-only data, it is useful to utilize a compressed file system. The following are used heavily in embedded systems:
See the File Systems page for more information.
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
- 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.
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.
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.
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.
You can save RAM memory by using some text or data directly from flash.
By executing the kernel in-place from flash, it is possible to save RAM space.
- see Kernel XIP
By executing applications in-place from flash, it is possible to save RAM space.
- see Application XIP
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. The range of kernels covered is from 2.6.12-rc2 to 2.6.17-rc1. Unfortunately, the system to
collect kernels and test them broke about the time of 2.6.17, and the system stopped operating at that 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.
- 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.
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.