[memory issue] i see a issue when i build demo with linux_x86 mode.
norman.feske at ...1...
Fri Jan 18 21:31:19 CET 2013
> > I find this value quite big on my 1 Gb computer while make run/sdl on
> Linux 64b:
> > spawn ./core
> > int main(): --- create local services ---
> > int main(): --- start init ---
> > int main(): transferred 17592186044415 MB to init
> > int main(): --- init created, waiting for exit condition ---
> platfrom()->ram_alloc()->avail() currently returns ~0 on base-linux,
> which is used to calculate the init_quota. At first sight it actually
> should match the size of _core_mem.
let me try out to shed some light on the confusing message and the role
The static array (originally called '_some_mem') was used to mimic the
physical memory model in line with the L4 base platforms. So core's
allocators would operate on it similarly of how core on L4 operates on
the physical RAM. Hence, the size of the array used to implicitly define
the initial quota of the init process. However, the static array was
just as a hackish solution cranked out at the very beginning of Genode's
development. It just stayed there because Genode on Linux was solely
used as a development vehicle by ourselves.
The original approach had several limitations. The most important being
that it artificially constraints the memory usable by the Genode system
- as just observed by Eunseok. Also, on Linux, Genode's quotas are
actually not at all effective. Because each Genode process is just a
Linux process, nobody is stopping it from allocating as much anonymous
memory (using mmap) as it wants - regardless of the quotas defined by
Now, with observing that Genode on Linux actually grows in popularity, I
revisited the code and abandoned the original static array. Here is the
Because Genode's quotas do not make too much sense on Linux anyway, I
decided to set the quota to the maximum value possible (~0). On 64-bit
systems, this looks a bit funny. So maybe we should use a more sensible
value instead. But in any case, it is pretty arbitrary.
So why is there still the '_core_mem' array? This one has actually
nothing to do with Genode's quota anymore. It is simply the backing
store for meta data allocated by core.
Apparently, the output Paul just posted is generated by a Genode version
newer than the patch. In contrast, the output Eunseok posted comes from
a version older than the patch.
The confusion is just perfect. ;-)
Dr.-Ing. Norman Feske
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
More information about the users