> DETAIL:
>
> 1. "zone.max-swap" resource control.
>
> Limits swap consumed by user process address space mappings and
> tmpfs mounts within a zone.
> zone.max-swap will be configurable on both the global zone, and
> non-global zones. The affect on processes in a zone reaching its
> zone.max-swap limit is the same as if all system swap is reserved.
> Callers of mmap(2) and sbrk(2) will receive EAGAIN. Writes to
> tmpfs will return ENOSPC, which is the same errno returned when
> a tmpfs mount reaches it's "size" mount option. The "size" mount
> option limits the quantity of swap that a tmpfs mount can reserve.
>
> 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.
While other controls seem to be capped by the process/thread's
project, it seems that use of swap like max-lwps might be
important for the global zone project 0. Has consideration been
given to allowing global zone "system" processes to not be
bound by GZ zone.max-swap?
It might be better than having to reboot or boot single to fix
a problem that could otherwise be fixed in the GZ.
Gary..
_______________________________________________
zones-discuss mailing list
[email protected]
