Resource trading between client and server

Norman Feske norman.feske at genode-labs.com
Thu May 14 15:19:00 CEST 2020


Hi Roman,

On 14.05.20 11:31, Roman Iten wrote:
> So far so easy. Now imagine that server is a child of server_init and
> client is a child of client_init. Both init's are siblings. I would
> expect that still client - and only client - has to pay for the
> server-side allocations. But the session creation fails when client_init
> and/or server_init assigned all of it's resources to it's children
> (RAM/CAP quota saturation).

your intuition is completely right. The client should pay. That's the
way it should work. That being said, two heads-ups from my side:

First, the server_init approach is still rather sparsely used. In
contrast to regular servers, the accounting of session resources has not
been stressed much in this scenario. So maybe you're hitting a corner
case not covered so far.

Second, the intermediate init instances need to maintain meta data about
the sessions. The memory for this metadata is meant to be drawn from the
client-provided session quota when forwarding the request towards the
server. However, the calculation of quota is performed at a sub-page
granularity whereas the allocations of meta-data objects always work on
a multiple of pages. This is why the RAM preservation comes into play.
It gives init some room to breath.

I'd be interested in knowing how exactly the session creation fails. Can
you be more specific about what happens? Or can you share a minimally
complex example scenario so that I can have a closer look?

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.genode.org/pipermail/users/attachments/20200514/ac75d323/attachment.sig>


More information about the users mailing list