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

Reply via email to