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 firstname.lastname@example.org