Steve Lawrence wrote:
On Tue, Oct 31, 2006 at 10:59:23AM -0800, Gary Winiger wrote:

  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.

This is how we treat cpu-shares. project 0 in the global zone has "infinite"

This will not help root logins directly, but could by setting:

        usermod -K project=system root

Would it be reasonable to propose special treatment of the global project 0
for all project and zone rctls?  Once could argue that capping system daemons
can only lead some sort of undesireable system failure.

This would of course exempt all global zone system daemons from resource
management.  To mitigate this, SMF could be leveraged to run application
daemons (or leaky/bad system daemons) in other projects.

Please don't do that in a hardcoded way. I don't mind if it is the default but it can't be hard coded. One of the main reasons we have nfsd (and kcfd) is so that resource controls can be placed on system services.

With the advent of SMF this is actually really easy to do since you
just need to set the project/pool the start method runs in.

Also it is perfectly reasonable to have a case where no "useful" customer work happens in the global zone, ie it is a service processor
really, and all the real work happens in the non global zones.

Darren J Moffat
zones-discuss mailing list

Reply via email to