First off, sorry for the stutter in the spec update mail.
> The project team didn't supply a summary of the changes, so I'll be
> asking for one in a follow on.
Summary of changes please.
> 1. This case proposes adding the following resource control:
> INTERFACE COMMITMENT BINDING
> "zone.max-swap" Committed Patch
> This control will limit the swap reserved by processes and tmpfs
> mounts within the global zone and non-global zones. This resource
> control serves to address the referenced RFE.
There was some considerable discussion on the global zone aspect
of this part of the proposal. Perhaps I missed in the spec how
the new proposal mitigates the risk of the global zone not being
able to administer the system.
> 1. "zone.max-swap" resource control.
> Limits swap consumed by user process address space mappings and
> tmpfs mounts within a zone.
> While a low zone.max-swap setting for the global zone can lead to
> a difficult-to-administer global zone, the same problem exists
> today when configuring the zone.max-lwps resource control on the
> global zone, or when all system swap is reserved. The zonecfg(1m)
> enhancements detailed below will help administrators configure
> zone.max-swap safely.
Perhaps I misunderstood the interaction between project 0
and zone.max-lwps in the global zone. If a max-lwps is set
is project 0 bound by it?
Perhaps a short summary of the offline discussion on project 0
and the project teams feeling that the discussions conclusions
might not be patch qualified. I realize the need for this project
to have a patch binding.
> 2. "swap" and "locked" properties for zonecfg(1m) "capped_memory"
> To prevent administrators from configuring a low swap limit that
> will prevent a system from booting, zonecfg will not allow a
> swap limit to be configured to less than:
> Global zone: 100M
> Non-global zone: 50M.
> These numbers are based on the swap needed to boota zone after a
> default installation.
> Also, if zone.max-swap is configured (via zonecfg(1m)) on the
> global zone, a warning will be printed:
> global:capped-memory> set swap=200M
> Warning: Setting capped swap on the global zone can impact
> system availability.
> Similar warnings will be printed for setting other rctls on the
> global zone which can affect availability, such as zone.max-lwps.
I don't doubt that 100M and 50M are currently reasonable numbers,
however, how will they be tracked (computed/changed) in future.
zones-discuss mailing list