virtual memory usage of base-linux components

Norman Feske norman.feske at
Tue Feb 18 09:42:07 CET 2020

Hi Pirmin,

> `strace` showed that the component that wasn't running (often timer) was
> terminated very early with SIGSEGV. A look at htop showed that each
> Genode component uses about 420 MB of virtual memory. lx_hybrid
> components on the other hand "only" about 170 MB.
> Can anybody give me some hints on where should start my quest to reduce
> the virtual memory footprint of Genode components on base-linux?

the major part of the virtual-memory need stems for the reserved
address-space ranges for the stack area and the linker area. Strictly
speaking, those virtual memory ranges are not actually "used" but they
are marked as reserved to prevent the Linux kernel from installing
mappings within these ranges, e.g., when the application attaches a
dataspace to its local address space.

You can find the relevant definitions for linker area at [1] and for the
stack area at [2]. Note that the latter definition is Linux-specific.


According to these definitions, the linker area covers a virtual address
range of 160 MiB whereas the stack area covers 256 MiB. The sum is 416
MiB. The remaining 4 MiB is used by the ELF segments of the dynamic
linker and dataspaces attached by the actual application.

For hybrid components, the linker area remains unused, which explains
the lower footprint.

The easiest way to reduce the footprint would be to lower the values of
the definitions. However, I'd instead recommend investigating a way to
exclude merely reserved areas from the accounting. If there was a way to
clearly distinguish the actual "use" of virtual memory from mere
"reservation" in the policy, the policy could be much more ridgid.

To investigate the virtual address-space layout of a given Genode
component running on Linux, I recommend looking at the corresponding
/proc/<PID>/maps pseudo file. There you can quite clearly see the
distinction between the reserved areas and areas backed by RAM, i.e.,
the entries that point to the "ds" (dataspace) files.


Dr.-Ing. Norman Feske
Genode Labs ·

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

More information about the users mailing list