On Thu 26 Oct 2006 at 11:50AM, Steve Lawrence wrote:
> "size of process image" is pretty meaningless. If we can change "pr_size" to
> be "swap reserved by process", then we could change "SIZE" to "SWAP" for all
> prstat(1m) output. Would such a change to psinfo_t be reasonable?
You'd have to check in with Roger, I think (and doing so would probably
be worth doing anyway). Adding a new field might be feasible.
> > > Currently a global or non-global zone can consume all swap
> > > resources available on the system, limiting the usefulness of zones
> > > as an application container. zone.max-swap provides a mechanism to
> >
> > I would rephrase that as "the container of an application" to avoid
> > confusion with the Solaris feature set called "Containers." I assume that
> > the former was meant moreso than the latter even though Containers are
> > Solaris' implementation of "an application container."
>
> I'm not sure what you mean, but ok. By "the Solaris feature set called
> Containers.", do you mean "zones + RM", or do you mean "zones, xen, ldoms".
Steve, I think the text is fine. This document isn't intended for
consumption by customers, and the text is clear enough to anyone trying to
absorb its meaning.
> > Similarly, the ability to modify a zone's swap
> > limit could be given to the zone's root user, which might be valuable in
> > some situations. This would be analogous to the 'basic' privilege level.
> > It would allow an advisory limit to be placed on a zone - a limit that the
> > zone admin could modify in unusual circumstances.
> >
> > I just wanted to mention this idea so that it is not unintentionally
> > overlooked.
>
> Currently, all zone.* rctls are not modifiable from a non global zone.
>
> The established mechanism for a zone admin to set rctls within the
> zone is via project.* rctls set on projects within the zone. Granted, in
> the "zone.max-swap" case, we are not proposing a "project.max-swap", due to
> implementation complexity and risk. With sufficient customer damand, we could
> investigate implementing "project.max-swap" in the future.
I think I'd agree that allowing a zone to modify its own zone.* rctls
(perhaps only to lower them) is something we *could do* at some point.
But I'm aware of neither an RFE for this nor stated customer demand.
If someone wants this, then let's get that recorded as an RFE in the bug
database, please.
Thanks,
-dp
--
Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
