Remember that FSS is designed to provide a minimum, but not a max.
Depending on CPU use by other threads in the class, a given thread may
get more than it's alloted CPU shares, but it will never get less.

/jim


Brian Kolaci wrote:
Jeff Victor wrote:
Brian Kolaci wrote:


I've been discussing about how to chop up a machine. An possible example
configuration would have 8 cpus, 3 local zones.  They would possibly be
divided up as 50%, 25% and 25%.  Its clear how to do this with pools,
however FSS is a great fit for when a zone may need more CPU than whats
available in the pool/psrset. The problem with FSS in this case is that
if one zone is mostly idle and all the other zones are busy, the zone
that is idle will get a load average much higher than its really using
which can skew the calculations use by the sendmail process to determine
if the queue/refuse connection thresholds are met.


How does FSS make that situation worse? The misleading [1] load avg is not affected by FSS, which is merely enforcing the minimum CPU-power portions that you chose. If they are inappropriate, prctl can be your friend. :-)


[1] "misleading" for this situation, not so for others.

I guess what I mean is that with FSS, people get the impression
that they are dividing the resources fairly among the zones but the
misleading load average tells processes that they're already using
all or more than their share already.  Agreed, its not really a problem
of FSS, but that the load averages reported in a zone do not reflect
what it actually is in the zone, but of the processor set it is associated
with.
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to