On Tue, Oct 31, 2006 at 10:59:23AM -0800, Gary Winiger wrote:
> > 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.

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

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. 

Perhaps this issue should be run as a seperate fasttrack?  I need to 
investigate the implementation impact.

-Steve

> 
> Gary..
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to