Session quota yielding

[Charles HH]

Hi,
I am currently using a Loader to deploy a subsystem, and in order to
improve dynamism, I would like to implement resource trading between the
Loader session client and the server. For resource requests, this is pretty
straightforward using a notification and the upgrade session facility.
However, I would also like the loader to be able to spontaneously yield
resources when they are no longer needed. I looked at the yielding
facility, but it seemed more focused on direct parent/child trading.
Is there a way for a server to yield back resources to its clients
symmetrically to the upgrading protocol, ideally that doesn't require
modifying the parent interface?

Regards,
Charles

[Norman Feske]

Hello Charles,

Post by Charles HH
Is there a way for a server to yield back resources to its clients
symmetrically to the upgrading protocol, ideally that doesn't require
modifying the parent interface?

there is currently no inverse operation of a session upgrade. A client
has to close a session to regain the resources.

I'd be interested to learn more about your particular use case as the
parent and root interfaces will undergo a revision soon (turning
blocking RPC calls into asynchronous interactions). So I wonder if your
use case may contribute to the new design?

Cheers
Norman

[Charles HH]

Hi Norman,

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.

Because of the absence of session quota yield, I was thinking of
implementing some sort of freed resource pool in the loader that would be
used (with validation from the centralized component of course) before
requesting a session upgrade. That approach doesn't seem satisfying though,
because I would have to change the one loader-session per subsystem and
permit potential resource stealing/leaking between them.

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?

Regards,
Charles

Post by Norman Feske
Hello Charles,

Post by Charles HH
Is there a way for a server to yield back resources to its clients
symmetrically to the upgrading protocol, ideally that doesn't require
modifying the parent interface?

there is currently no inverse operation of a session upgrade. A client
has to close a session to regain the resources.
I'd be interested to learn more about your particular use case as the
parent and root interfaces will undergo a revision soon (turning
blocking RPC calls into asynchronous interactions). So I wonder if your
use case may contribute to the new design?
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
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main

[Norman Feske]

Hi Charles,

Post by Charles HH
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?

Post by Charles HH
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