This content has been marked as final. Show 1 reply
In a nutshell, caps set an upper bound and shares set a lower-bound for the amount of CPU that a zone gets.
As stated in zonecfg(1M):
If you set a capped-cpu to 2 on a 16 processor machine, the zone will never get to use more than the equivalent of two CPUs. That is, it could end up with lots of things in the run queue while the system has idle processors because the zone has hit its CPU cap.
Sets a limit on the amount of CPU time that can be used by a zone. The unit used translates to the percentage of a single CPU that can be used by all user threads in a zone, expressed as a fraction (for example, .75) or a mixed number (whole number and fraction, for example, 1.25). An ncpu value of 1 means 100% of a CPU, a value of 1.25 means 125%, .75 mean 75%, and so forth. When projects within a capped zone have their own caps, the minimum value takes precedence. The capped-cpu property is an alias for zone.cpu-cap resource control and is related to the zone.cpu-cap resource control. See resource_controls(5).
zone.cpu-shares interacts with the fair share scheduler. It goes with the idea that a CPU is a terrible thing to waste. By setting the CPU shares for a particular zone to a value, it makes the zone get a minimum of a calculated percent of CPU if it is needed. The percentage that the zone gets is based on:
(this zone's zone.cpu-shares) / sum(zone.cpu-shares across all zones)
So, if z1, z2, and z3 are zones with 10 50 and 40 CPU shares, z1 would get at least 10% (10 / (10 + 50 + 40)) of the CPU time, z2 would get 50%, and z3 would get 40%. However, if z2 and z3 are idle, z1 could use 100% of the system's CPU resources.