>If there is room, the cpu will be used. When things get tight, the RG cap >will be enforced.
RGs are always enforced, that os what they are for: To limit the processor capacity available to work in service classes connected to the RG, no matter how much is available. And I believe that this might be the point where Tracy's setup fools him. I understand he's using a type 3 resource group, limiting the processor capacity based on a percentage of *CP* capacity. That capacity value is purely based the SU/s a single CP can deliver in the given LPAR configuration. The number of LCPs assigned to an LPAR decides how many SU/s a single CP can deliver. From this the percentage is calculated. This value does not change with neither the LPAR's fair share (weights) nor with defined capacity. We're using type 2 RGs where we define a percentage of the LPAR capacity, which is calculated based on the *currrent* LPAR capacity, i.e. it fair share (weight) or defined capacity (soft cap). The manual explicitly states that the value is readjusted when the LPAR is being soft capped. We limit the capacity batch can used in periods where we're not capped, which helps us to "set aside" some of the rolling 4 hour average for the time when online kicks in. Hould we still run into soft capping, the batch's capacity is still the same percentge but not from the capped capacity. We defined one Resource Group and have assigned most of the batch Service Classes to that RG. Then we defined a couple of Service Policies, each one overriding the RGs upper limit, e.g. 10%, 12%, 14%, etc.. We do not set lower limit (lower limits are enforced even if it would hurt higher importance work! Not what we want.). In the base policy, the RG has *no* upper limit specified. So, when we run with the base policy, nothing is limited via RG, because there are no limits set. When need arises, we simply switch to another policy, based on what limit we want to set. We're having good success with this. -- Peter Hunkeler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
