Steve Lawrence wrote:
>On Sat, Nov 11, 2006 at 09:02:48PM -0800, Gary Winiger wrote:
>
>
>> 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.
>>>
>>>
>
>I've addressed your comments way below. Here is my change summary and case
>discussion summary:
>
>SUMMARY OF CHANGES
>
>1. Change to the proposed uncommitted kstat names and statistics.
> From the form:
>
> zone:{zoneid}:vm
>
> with statistics:
> zonename
> swap_reserved
> max_swap_reserved
> locked_memory
> max_locked_memory
>
> To the form:
>
> caps:{zoneid}:swaprsev_zone_{zoneid}
> caps:{zoneid}:lockedmem_zone_{zoneid}
> caps:{zoneid}:lockedmem_project_{projid}
>
> with statistics:
> zonename
> usage
> value
>
> This sets up a generic scheme for adding kstats to project and
> zone rctls. A kstat is created per rctl, instead of per zone.
>
>2. Addition of zonecfg(1m) minimums for setting zone.max-swap.
>
> When setting zone.max-swap via zonecfg(1m), a minimum value will be
> enforced:
>
> global zone: 100M
> non-global zone: 50M
>
> Currently, this is about 20M more than is needed to boot after a
> default installation.
>
>3. Addition of zonecfg(1m) warnings when setting zone.max-swap and
> zone.max-lwps on the global zone.
>
> global:capped-memory> set swap=200M
> Warning: Setting capped swap on the global zone can impact
> system availability.
>
>SUMMARY OF CASE DISCUSSION:
>
>The case disussion has focused on the problem that the zone.max-swap
>rctl on the global zone can affect system availability. An identical
>problem exists today with task/project/zone.max-lwps.
>
>Solutions to this problem may involve one or more of:
>
> - Exempting project 0 in the global zone from zone.* rctls.
> - Preventing task/project.* rctls from being set on project 0
> in the global zone.
> - Modifying root's default project.
> - Adding a new privilege to exempt a process from rctls.
> - Updating system service manifests to drop the new privilege.
>
>Solving this problem in a way that will prevent the global zone (on a
>default system) from becoming unavailable due to a resource control setting
>will require a signficant change to the system. I believe solving this
>problem is outside the scope of the "zone.max-swap" case, and would be better
>solved by another case which is "not" seeking patch binding.
>
>To minimize this problem for zone.max-swap (and zone.max-lwps), I've instead
>proposed zonecfg enhacements to assist the admin in configuring these rctls
>safely.
>
>
>
>>> 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[6].
>>>
>>>
>> 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.
>>
>>
>>
>>>DETAIL:
>>>
>>> 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?
>>
>>
>
>Currently yes. zone.* rctls bound all processes in the global zone, regardless
>of project. This is the issue that my "other" proposal is attempting to
>address.
>
>
>
>> 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.
>>
>>
>
>I've added this summary above.
>
>
>
>>> 2. "swap" and "locked" properties for zonecfg(1m) "capped_memory"
>>> resource.
>>>
>>>
>>> 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.
>>
>>
>
>Good question. These are essentially "virtual system requirements".
>
>
What is the behaviour of Solaris intended to be when someone
makes these changes (or attempts to make them) on a system
that has no swap space?
Furthermore, why shouldn't I be able to say a zone has no swap
space available to it - i.e. to force it to all run from RAM?
Darren
