(Just one project listed so far).
Here are some links to information and projects related to Linux system size.
Contents
Documentation on reducing kernel size
CELF is working on a comprehensive document on the subject of measuring and reducing the size of the Linux kernel. There is a draft of this document on the following page:
Technologies for decreasing system size
The Linux-tiny patchset
see the LinuxTiny page
CELF is working on a project to characterize the sub-patches in the Linux-tiny patchset, in order to prioritize them for porting to non-x86 architectures.
Compiler options for reducing kernel size
An LWN article talks about three gcc options to shrink the kernel.
http://lwn.net/Articles/67175/
The first is -Os which is already in the tiny kernel patch.
The second is new in gcc 3.4, -funit-at-a-time, it 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, -mregparm=3, seems to be x86 specific, it instructs the compiler to use registers for the first three function arguments.
- -- John Rigby
SquashFS file system
For read-only data, it is useful to utilize a compressed file system. The following are used heavily in embedded systems:
- Cramfs - [should put some information or link here]
SquashFS - see the SquashFs page
Use of a smaller libc
- ucLibc - small footprint C library
SubsetLibcSpecification - CELF is researching the possibility of creating a subset libc specification
Kernel XIP
By executing the kernel in-place from flash, it is possible to save RAM space.
see KernelXIP
Application XIP
By executing applications in-place from flash, it is possible to save RAM space.
see ApplicationXIP
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.
see DataReadInPlace
Size measurement tools and techniques
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 RuntimeMemoryMeasurement for a description of ways to measure runtime memory usage in Linux.
Also, see AccurateMemoryMeasurement 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 SzwgLinux26Data 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.
Case Studies
Motorola reduction of system size (presumably for cell phones) using 2.4 Linux: see MotSizeReduction.ppt
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.