Using Static Share Quota to Minimize Reclaims Across Multiple Resource Groups

This feature works in conjunction with dynamic share pool scheduling and is used to minimize the number of reclaims that can occur when consumers are overusing resources from multiple resource groups.

Scope


Applicability

Details

Operating system

  • All host types supported by the Symphony system

Exclusions

  • Does not apply to Symphony DE, which does not have resource lending, borrowing, and reclamation


How dynamic share pool scheduling works

Dynamic share pool scheduling is defined as the scheduling policy in effect when EGO_ADJUST_SHARE_TO_WORKLOAD is enabled in the ego.conf file; see Adjustable Share to Workload for Resource Allocation/Reclaim for details. To better understand how static share quota can be used to minimize the number of reclaims, let’s review how dynamic share pool scheduling works.

With dynamic share pool scheduling, if only one consumer has demand, it deserves 100% of the share pool. If there are multiple resource groups, EGO tries to allocate resources from one resource group after another, which means that a consumer will use all the resources up to its "dynamic share quota" from the first resource group before it gets resources from the next one. Dynamic share quota takes into account the static share ratio and the workload that consumers are running in the resource group at that moment. For example:

  • 3 consumers : A, B, C

  • static share ratio: 1:2:3

  • 1 resource group (RG1) with a total of 18 slots

If only A has workload, its dynamic share quota is 18 slots. If A and B have workload, the dynamic share quota for each consumer will be A=6 slots and B= 12 slots.

If the first resource group is completely used up when a second consumer has demand, that consumer will use free slots in the remaining resource groups. If EGO cannot satisfy the second consumer’s entire demand after trying to allocate resources from all of the resource groups, the dynamic share quota for each resource group is applied, which can result in unnecessary reclaims. In this case, since the first consumer is overusing resources in the first resource group, its resources will be reclaimed because the second consumer still has unsatisfied demand.

Here is an example of dynamic share pool scheduling with the static share quota feature disabled.

Configuration:

  • Resource group RG1 : 20 slots

  • Resource group RG2 : 20 slots

  • Consumer A : share ratio 1; resource group: RG1, RG2

  • Consumer B : share ratio 1; resource group: RG1, RG2

  • Consumer C : share ratio 1; resource group: RG1, RG2

About this feature

Applying static share quota to dynamic share pool scheduling

When this feature is enabled, EGO first attempts to allocate resources from each resource group according to the consumer’s "static share quota". The static share quota is derived from the static share ratio for the consumer and the total number of slots in the resource group. For example:

  • 3 consumers: A, B, C

  • static share ratio: 1:2:3

  • 1 resource group (RG1) with 18 slots

Given the preceding configuration, the static share quota of A=3 slots, B=6 slots, and C=9 slots in RG1.

If EGO cannot allocate the consumer’s static share quota of resources because there are not enough idle slots in a resource group, EGO tries to allocate slots from another resource group.

If a consumer has unsatisfied demand after being allocated its static share quota for each resource group, EGO allocates additional resources up to the consumer’s dynamic share quota starting with the first resource group. If the consumer still has unsatisfied demand after all the resources are allocated from the first resource group, EGO allocates resources from the second resource group, and so on. (The order of resource groups is defined by the order that they appear in ConsumerTrees.xml.) As a result, resources used to satisfy the dynamic share quota will not be taken evenly from each resource group.

How resources are reclaimed when the feature is enabled

As long as a consumer is consuming within its static share quota for the resource group, the consumer will never be considered to be overusing resources. EGO considers the consumer’s dynamic share quota first when deciding if a consumer is overusing resources.

Reclaiming resources is performed in the following order. In each case, EGO reclaims resources from consumers that are exceeding their dynamic share quota.

  1. If a consumer is not able to get its static share quota from idle slots

  2. If a consumer is not able to get its dynamic share quota from idle slots

Using the earlier example of three consumers and two resource groups, the following shows how slots are allocated and reclaimed when the feature is enabled.

As can be seen in the example, since the resource distribution order was done according to the consumers’ static share quota in each resource group, the number of reclaimed slots is reduced significantly.

Enabling the feature to minimize reclaims


Configuration source

Setting

Behavior

ego.conf

EGO_ENABLE_BASE_QUOTA=y

When set to y, specifies that resources will be allocated to consumers according to their static share quota from each resource group first, followed by resources allocated according to the order of resource groups defined in ConsumerTrees.xml. The default value is n (not enabled).

Note:

For this feature to work, you must also enable EGO_ADJUST_SHARE_TO_WORKLOAD in ego.conf.