Quota Preservation

Nobody III hungryninja101 at ...9...
Fri Feb 16 11:18:22 CET 2018

Hmm. I still strongly prefer my original idea. In particular, I don't want
to run out of RAM quota with hundreds of MB of physical RAM unused. Can you
help me understand your reasoning here?

What is the status of how init handles quotas? Specifically, can a
component go above its quota if init has more RAM available?

What happens when a component runs out of RAM quota? How much RAM quota is
required to start a process?

How are you imagining such a "desktop manager" would work? In particular,
how would it know when a process needs more RAM (or CAPs)?

Is there a way to know how much RAM (and CAP) quota init has left?

On Feb 16, 2018 2:01 AM, "Norman Feske" <norman.feske at ...1...>

Hi Ben,

sorry that your previous posting remained unanswered.

> The RAM preservation feature in init is very nice; I used to have issues
> with init running out of memory. However, the RAM reservation applies
> after first reserving the RAM for all of the child processes based on
> their quotas. That may be fine in most cases, but it doesn't work
> properly when you give a child process a huge RAM quota to ensure that
> it gets all of the available RAM. In that situation, the RAM
> preservation happens after all of the available RAM has been reserved
> for the child processes, leaving no RAM available for init to preserve
> for itself. Something needs to change here.

Thanks for raising this issue. Just to make sure it does not go
unresolved, would you mind to open an issue at GitHub and possibly give
instructions how to reproduce it?

> Changing the ordering is the simplest solution, but there may be a
> better solution. When we reserve all the remaining RAM for a particular
> process, we supply a huge RAM quota that is much larger than the process
> actually needs. It seems that the solution would be to split
> the quota numbers into a minimum (amount *reserved*) and a maximum
> (amount *available*). It would work very nicely for standard desktop
> workloads, especially when web browsers are involved. For example, I'd
> like to ensure that chromium has access to up to 2G of RAM, if it is
> available, but I don't want to reserve 2G of RAM specifically for
> Would this solution work well? Or is there something that I'm missing

I am not convinced of this approach. Even though I can relate to the
described scenario, to me, the two statements sound like a contradiction:

1. Ensure that chromium has access to up to 2G of RAM
2. Don't want to reserve 2G of RAM specifically for chromium

The proper way to deal with the situation you described would be to
dynamically adjust the quota values for chromium (a "desktop manager"
could do that automatically). Init supports the dynamic change of RAM
quotas in the following ways:

* If the quota of a start node is increased, init transfers RAM
  quota from init to the component.

* If the quota is decreased, init tries to transfer RAM quota from the
  component to init. If this is not possible (because the component's
  PD has not enough unused RAM quota), init sends a 'yield' request
  to the component. A nice-behaving component could respond to such
  a request by freeing up the requested amount of RAM.

With this way, we can leave out the policy (like a softer notion of
quotas) outside of init.


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

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
genode-main mailing list
genode-main at lists.sourceforge.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20180216/45e3cdca/attachment.html>

More information about the users mailing list