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.
-Steve
>
> -dp
>
> --
> Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] -
> blogs.sun.com/dp
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
