Session quota yielding

[Norman Feske]

Hi Charles,

> My use case is a dynamic system with centralized resource management and
> control. I'd like to be able to instantiate specific-purpose subsystems
> isolated from each other and from the resource manager. When a subsystem
> is created, its launcher has to bargain with the manager (through the
> loader and a modified loader session) to obtain resources. It's a sort
> of fusion between the cli_monitor and the loader. The subsystems should
> however be able to yield back resources when, for example, one of their
> children exits.

thank you for providing more details. I am actually thinking in a very
similar direction: Like you, I want to manage subsystems dynamically but
don't want to implement the (potentially complex) management component
as the parent of the managed subsystems. My current idea is to enhance
init so that it will be able to respond to configuration changes in a
sensible way.

Right now, init replaces all children with new instances each time when
its configuration changes. In the future, I plan to let init apply only
the actual configuration changes. E.g., killing the subsystems that
disappeared in the new config, starting new subsystems for new appearing
<start> nodes, adjusting the resource assignments, or propagating
changes in the subsystem's respective <config> nodes. Furthermore, init
would produce reports about the state of the running subsystems, the RAM
usage, etc.

BTW, as far as I know, Johannes Schlatow already implemented a prototype
of this approach.

With the new (dynamic) version of init in place, CLI monitor would not
manage subsystems as its children any longer. It would merely generate
configurations for an instance of init that can live somewhere else in
the component tree. Alternatively to using CLI monitor, system scenarios
could be interactively modified on-the-fly by editing the config of a
dynamic init via Vim running inside Noux. Wouldn't that be cool? :-)

I wonder, would this principle design satisfy your use case, too?

> As a side question, how is the quota associated with a session
> registered? Is every component involved in the session creation
> responsible for remembering the quota it transfered?

Yes. The common parent of the client and server keeps those records.
This is natural because the common parent actually owns both client and
server and deliberately moves resource budgets between them. The
resource trading solely happens along the branches of the component tree.

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

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