restarting child components with resource saturation

Norman Feske norman.feske at genode-labs.com
Thu May 12 12:22:03 CEST 2022


Hello Pirmin,

I think the crux lies in the combination of init's dynamic
reconfiguration with resource saturation. There are multiple culprits.

First, you need to consider that once assigned resources cannot be
withdrawn without the consent of the subsystem. During the
configuration, components can temporarily disappear, which temporary
frees their resources. Now, when using the resource saturation
mechanism, those temporarily freed slack resources would end up in this
single subsystem. Whether or not you can eventually regain those
resources (without killing/restarting the subsystem) depends on the
behavior of the subsystem, which is presumably not what you want.

Second, resource peaks can occur during the dynamic reconfiguration in
the presence of chain reactions like in your case (the restart of the
vfs implies the restart of its clients, transitively...). During the
orderly destruction of inter-dependent components, init is required to
keep parts of disappeared components around to maintain their resource
accounting information until the chain reaction has settled. So it can
happen that two instances of the same component exist as an intermediate
state - the old one that just turned into some kind invisible zombi, and
the freshly started one. If the resources are fully saturated, this
usage peak cannot be accommodated.

As the bottom line, resource saturation should only be used for static
init configurations.

Regarding your specific problem: Since you are consuming init's state
reports already, couldn't you avoid the use of resource saturation by
using the reported 'avail_ram' and 'avail_caps' to dynamically assign a
sensible amount of resources to the runtime subsystem?

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



More information about the users mailing list