On Tue, Oct 31, 2006 at 12:02:58PM -0800, Gary Winiger wrote:
> > This is how we treat cpu-shares. project 0 in the global zone has "infinite"
> > shares.
> > This will not help root logins directly, but could by setting:
> > usermod -K project=system root
> Or perhaps deliver root's entry this way to start with.
Would that be a reasonable change to make via patch? Perhaps this change
could be delivered to nevada, but not backported.
It would be confusing to deliver this change, and also deliver the "user.root"
project. If we made root's default project "system", then the "user.root"
project should be removed. "user.root" is kind of a bug anyhow, as SMF does
not run root services in "user.root". Currently, only root processes spawned
by login/pam run in "user.root".
> > Would it be reasonable to propose special treatment of the global project 0
> > for all project and zone rctls? Once could argue that capping system
> > daemons
> > can only lead some sort of undesireable system failure.
> > This would of course exempt all global zone system daemons from resource
> > management. To mitigate this, SMF could be leveraged to run application
> > daemons (or leaky/bad system daemons) in other projects.
> leaky or bad system daemons should be fixed, but defining projects
> may well be a workaround ;-}
> > Perhaps this issue should be run as a seperate fasttrack? I need to
> > investigate the implementation impact.
> I'm looking for this case to define how to preserve the current
> model of "unlimited" unless one asks for a limit model in the
> global zone. I believe it is important from a system integrity and
> maintenance perspective. Other's may have different opinions.
> If there is a compelling reason to deliver in phases, please discuss
The global zone will have no swap limit by default. The default zone.max-swap
rctl delivered on the global zone is UINT64_MAX, which is essentially
unlimited. Is that what you mean?
zones-discuss mailing list