virtual memory usage of base-linux components
pirmin.duss at gapfruit.com
Tue Feb 25 13:36:57 CET 2020
On 18.02.20 09:42, Norman Feske wrote:
> Hi Pirmin,
> You can find the relevant definitions for linker area at  and for the
> stack area at . 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.
Using this method I was able to reduce the virtual memory size of
components quite a bit, but unfortunately not enough to run all
components of the scenario.
> 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.
The Linux kernel unfortunately doesn't provide the possibility to check
for only the used memory.
Discussing the possible solutions we had a cool idea which I think will
be my Hack and Hike project. The idea is to add a command line parameter
to core of base-linux where the user may specify the maximum amount of
memory core should provide to the initial init. In this way a Genode
scenario could never use more as the specified amount of memory.
Currently this can happen, if one uses memory saturation and the
component with the saturation has a memory leak error.
Not that this would solve our problem but would make restrain Genode
components on base-linux even more.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the users