Jerry Jelinek wrote On 08/01/06 10:16,:
Steffen Weiberle wrote:
Jerry Jelinek wrote On 08/01/06 09:32,:
Christine Tran wrote:
I found an old email written by Amol a while ago stating in effect
that zones.cpu-shares has no meaning when the system is carved up
into different pools. I would like some clarification, directly, I
have a customer who wants to attach one zone to one pool, and the
rest of the box, global and the rest of non-global zones can use the
default pool and use cpu shares. From Amol's old email, this cannot
be done. Can someone confirm this? Any supporting docs from Sun
would be appreciated as well.
That is just not correct. Using FSS on the one zone that has the
pset doesn't have any impact since those processes are not contending
with any other zone's processes for cpu resources. However, there is no
reason you cannot use FSS for the other zones, and the global zone,
their access to the rest of the shared cpu resources.
This suggests that if zones are not bound to a pool, they can be
limited via FSS. But aren't they technically bound to the default
resource pool? If so, and I have more than one zone bound to a
non-default resource pool, can I use FSS to limit the zones'
interaction on that pool?
Thanks for clarifying.
All zones can be limited by FSS. However, when you have a single zone
bound to its own dedicated pool/pset, then there are no other zones to
contend with, so the FSS will not be limiting the execution of the
in that zone.
OK, so it is not that it won't work, but that FSS only kicks in when CPUs are at 100% and with only
one zone bound to the pool, it is entitled to 100% anyway. When FSS can make a decision, the only
possible answer is 'yes', so to say.
If you have multiple zones bound to the same pool/pset, then FSS can be
to limit each zone within the pset.
zones-discuss mailing list