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.
[1] https://github.com/genodelabs/genode/blob/master/repos/base/include/pd_sessi... [2] https://github.com/genodelabs/genode/blob/master/repos/base/src/include/base...
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.
Cheers Norman