>   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.

zones-discuss mailing list

Reply via email to