Hi Ben,
On 16.02.2018 11:18, Nobody III wrote:
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?
Instead of adding heuristics (of handing out unused memory) to init, the policy can be implemented outside of init by the one who controls init's configuration.
The idea is that init is accompanied by another "manager" component that generates init's configuration and consumes init's status reports. There is a feedback loop between init and the manager component. This puts the manager component in the natural position to balance the quotas of init's children, and control the lifetimes of the children. However your quota policy may look like, you may replace/customize the manager component but leave init unchanged.
In Sculpt EA, the user plays the role of the "manager" component. But this role can be played by a program, too.
What is the status of how init handles quotas? Specifically, can a component go above its quota if init has more RAM available?
No. But init does reflect this situation in its state report. So a manager component can respond to such a condition by increasing the quota in init's config.
What happens when a component runs out of RAM quota?
If the component takes no special precautions, it would block until its RAM quota gets upgraded.
How much RAM quota is required to start a process?
This depends on the component, e.g., the binary size, BSS size, shared libraries.
Is there a way to know how much RAM (and CAP) quota init has left?
In init's reports, you can see how much RAM quota each child uses.
Cheers Norman