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.

−

−

== Technologies for decreasing system size ==

== Technologies for decreasing system size ==

Line 23:

Line 22:

According to gcc's manual, this option no longer does anything.

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

See [http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html] for all

available optimization switches.

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

==== Runtime size of kernel ====

Line 56:

Line 63:

||Total || 384k/768k || 1248k/2496k

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

+

+

=== Auto-reduction ===

+

In 2012, Tim Bird studied a few different techniques related to automatic size reduction and whole-system optimization.

+

Specifically, he studied the following items:

+

* link-time optimization of the kernel

+

* syscall elimination

+

* global constraints

+

* kernel stack reduction

+

+

Tim also found some very interesting academic research on link-time re-writing and cold-code compression.

+

Tim's work will be presented at LinuxCon Japan in May, 2013.

+

+

An outline for the talk is at [[System Size Auto-Reduction]]

=== File system compression ===

=== File system compression ===

Line 66:

Line 93:

See the [[File Systems]] page for more information.

See the [[File Systems]] page for more information.

+

=== Shrinking your application ===

=== Shrinking your application ===

Line 127:

Line 155:

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

* [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 221:

Line 251:

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 228:

Line 260:

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

+

* There is a project called Poky-tiny, to produce an extremely stripped-down distribution of embedded Linux using the Yocto project.

+

** See https://wiki.yoctoproject.org/wiki/Poky-Tiny

+

** Poky-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

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

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.

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.

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.

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.htmlThis program appears to be obsolete now. I couldn't get it to compile on Fedora 8.

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.

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.

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.

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.

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

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.

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.