> 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@example.com