On Tue 31 Oct 2006 at 04:10PM, Steve Lawrence wrote:
> On Tue, Oct 31, 2006 at 03:28:31PM -0800, Dan Price wrote:
> > On Tue 31 Oct 2006 at 03:24PM, Steve Lawrence wrote:
> > > It seems reasonable to amend this case to say:
> > >
> > > 1.
> > > Any process with priv_sys_resource running in the global zone's
> > > system project (project 0) will not subject to project.* or zone.*
> > > resource controls. System daemons which wish to be subject to the
> > > global zone's resource controls can drop priv_sys_resource.
> >
> > This "feels" risky for a patch... the effect here is to "un-manage"
> > things which the customer may be expecting to be resource managed,
> > potentially including a workload. Or is the point that no-one using
> > RM will be relying on the system project to limit things?
> >
> > This implies that can't give the system project 10 (or 100) shares
> > after this proposal?
>
> For shares, you can't do this now anyway. The system project implicitly has
> infinite shares, regardless of what shares you have set. This is documented
> in FSS(7):
>
> By default, project system (project ID 0) includes all sys-
> tem daemons started by initialization scripts and has an
> "unlimited" amount of shares. That is, it is always
> scheduled first no matter how many shares are given to other
> projects.
>
> I've proposed extending this for all resource controls, not just *.cpu-shares.
My apologies... I should've done some more digging first.
-dp
--
Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
