This patch mirrors the accounting and trading scheme that Genode employs
for physical memory to the accounting of capability allocations.
Capability quotas must now be explicitly assigned to subsystems by
specifying a 'caps=<amount>' attribute to init's start nodes.
Analogously to RAM quotas, cap quotas can be traded between clients and
servers as part of the session protocol. The capability budget of each
component is maintained by the component's corresponding PD session at
core.
At the current stage, the accounting is applied to RPC capabilities,
signal-context capabilities, and dataspace capabilities. Capabilities
that are dynamically allocated via core's CPU and TRACE service are not
yet covered. Also, the capabilities allocated by resource multiplexers
outside of core (like nitpicker) must be accounted by the respective
servers, which is not covered yet.
If a component runs out of capabilities, core's PD service prints a
warning to the log. To observe the consumption of capabilities per
component in detail, the PD service is equipped with a diagnostic
mode, which can be enabled via the 'diag' attribute in the target
node of init's routing rules. E.g., the following route enables the
diagnostic mode for the PD session of the "timer" component:
<default-route>
<service name="PD" unscoped_label="timer">
<parent diag="yes"/>
</service>
...
</default-route>
For subsystems based on a sub-init instance, init can be configured
to report the capability-quota information of its subsystems by
adding the attribute 'child_caps="yes"' to init's '<report>'
config node. Init's own capability quota can be reported by adding
the attribute 'init_caps="yes"'.
Fixes#2398
The 'diag' flag can be defined by a target node of a route in init's
configuration. It is propagated as session argument to the server, which
may evaluate the flag to enable diagnostic output for the corresponding
session.
Issue #2398
This patch replaces the former use of size_t with the use of the
'Ram_quota' type to improve type safety (in particular to avoid
accidentally mixing up RAM quotas with cap quotas).
Issue #2398
This patch removes the formerly built-in policy of responding to
resource requests with handing out slack quota. Instead, resource
requests have to be answered by an update of the init configuration with
adjusted quota values.
Note that this patch may break run scripts that depend on init's
original policy. Those run scripts may be adjusted by increasing the
quota for the components that use to inflate their RAM usage during
runtime such that the specified quota suffices for the entire lifetime
of the component.
This patch improves init's dynamic reconfigurability with respect to
adjustments of the RAM quota assigned to the children.
If the RAM quota is decreased, init withdraws as much quota from the
child's RAM session as possible. If the child's RAM session does not
have enough available quota, a resource-yield request is issued to
the child. Cooparative children may respond to such a request by
releasing memory.
If the RAM quota is increased, the child's RAM session is upgraded.
If the configuration exceeds init's available RAM, init re-attempts
the upgrade whenever new slack memory becomes available (e.g., by
disappearing other children).
