Please note that User Registration has been temporarily disabled due to a recent increase in automated registrations. If anyone needs an account, please request one here: RequestAccount. Thanks for your patience!--Wmat (talk)
Please email User:Wmat if you experience any issues with the Request Account form.

Difference between revisions of "System Size"

From eLinux.org
Jump to: navigation, search
(Documentation on reducing kernel size: add link to Kleen paper)
Line 4: Line 4:
 
[[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]] is a draft of a document on the subject of measuring and reducing the size of the Linux kernel
  
* [[Kernel Size Tuning Guide]]
+
* [[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
+
* 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 ==

Revision as of 20:19, 26 July 2007

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

Technologies for decreasing system size

The Linux-tiny patchset

  • see the Linux Tiny page. There is a project to characterize the sub-patches in the Linux-tiny patchset, in order to prioritize them for porting to non-x86 architectures.
  • see Linux Tiny Test Project

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.

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

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 Squash Fs page

Use of a smaller libc

  • uClibc - small footprint but complete C library
  • klibc - very small library for use in init ram filesystems
  • dietlibc - another library to produce very small statically compiled executables.
  • Subset Libc Specification - 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.

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.

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 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. 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.

See this post by Linus Torvalds