Why application request RAM quota from parent even if it is enough?

[Norman Feske]

Hi Alexander,

our discussion intermingles two topics that should better stay separated.

(A) How to overcome the road block of the Go runtime depending on an
mmap feature, which is not available on Genode?

(B) What happens when a component runs out of memory?

> Here I see some contradiction - in our (and most, probably) cases we
> write child process and software, not parent. I even don’t know who my
> parent in that case. In normal Unix/Wndows/etc I know that this could be
> some kind of aux processes provided to me by OS on which I don’t have
> any power.
> So, may be it worth to have a separation between «own intentional
> distributed inside OS (like genode) or over net application childs» and
> single application as a child of extenrally (not mine!) provided parent? 

I'm sorry about the confusion. I should have been more specific. Does my
reply to Cedric [1] clarify that question?

[1] https://lists.genode.org/pipermail/users/2019-September/006902.html

> And, my hard believe that any application can’t «just hangs» in any
> case. At least, in production environment.
> Even for research/educational ones - I can’t understand why, if I
> configure system wrongly, it just demonstrate black screen, without any
> reasonable way to find a reason (can’t attach debugger - not supported
> on my configuration, and I even don’t know the stack of hanging
> application/rom module/etc, as it happens with me).

I agree. I think you got me wrong. I did not want to suggest infinite
blocking as an acceptable general solution. But in the static part of
the system (the part spawned by the first init instance), resources
_are_ statically partitioned. If those static boundaries are violated by
one component, the static system ensures that unrelated components are
not affected. But it won't magically make the misbehaving component work.

Since there is no general answer to the question of what should happen
when a component behaves unexpectedly, the Genode base system does not
even try to implement a policy. Instead, it offers a mechanism - the
dynamically configurable init I described in my reply to Cedric - that
allows you to implement a policy you see fit best.

> I get stuck for some time, now I found some ways, like ask to reserve
> only 1 gb of ram and try to run everything here, it is somehow supported
> for mipsle platform.
> Now I am stuck again in the setting up of signal processing…
> All these requires efforts in trying to fix runtime code doing some
> nasty things before even main program.
> The next potential problem I expect in stack switching (used by go
> coroutines), and, may be in stack growth (temporary I disable common gcc
> mechanism from morestack.c).
> Hope to have soon running helloworld application from go.

You spent most of your email discussing topic (B). It's good that you
raised the issue, so that Cedric could jump on it, and I had a chance to
promote Genode's approach.

However, in the context of your pressing problem at hand (A) and the
other nasty technicalities you mentioned above, the discussion of (B) is
a distraction, isn't it? It does not help you progressing with (A).

That said, I don't have any magic spell for overcoming (A)
unfortunately. Intuitively, I'd try to change the memory-allocation
backend of the runtime, just like I stated in my previous posting. But
since I haven't looked into the Go runtime myself, I unable to
substantiate that.

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

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