One implication of negotiator splitting (Consumption Policies) is that the negotiator is responsible for matching all requests. In an large-scale pool, this may make the negotiation cycle the rate-limiter for resource allocation. A pool can support multiple schedulers, so scheduler splitting (CLAIM_PARTITIONABLE_LEFTOVERS) can scale by increasing the number of schedulers running on the pool.
{section: Consumption Policies and Accounting}
-{subsubsection: slot weights and accounting groups}
-When working with Consumption Policies, it is useful to adopt a convention where slot weight represents a measure, or estimate, of *the number of jobs that can be serviced by a slot*. For example, suppose a slot is configured with a very coarse-grained consumption policy for memory. Then memory might be your primary rate limiter:
-
-{code}CONSUMPTION_MEMORY = quantize(target.RequestMemory, {1024}){endcode}
-
-So an appropriate slot weight that measures expected jobs that could be serviced by this slot would be:
-
-{code}SLOT_WEIGHT = floor(Memory / 1024){endcode}
-
-If the slot has 4096 MB of memory, than the above policy implies that an expected 4 jobs that can be serviced (note that each job consumes at least one chunk of 1024MB).
-
-An advantage of this convention is that it allows the negotiator's matchmaking to add up the pool's slot weights to obtain a measurement of how many jobs can be serviced by all of the resources. This is especially helpful for working with Accounting Group Quotas, since it makes the one-dimensional group quota computations work smoothly with slots having different consumption policies and different slot weights, and allows compatible comparisons with running and idle jobs.
-
{subsubsection: match cost}
The match cost for a job against a slot with a Consumption Policy is the _change_ in the SlotWeight value from before the match to after. It is this match cost value that is added to the corresponding submitter's usage in the HTCondor accountant. A useful way to think about accounting with Consumption Policies is that the standard role of SlotWeight is replaced with the change in SlotWeight.
@@ -73,7 +60,7 @@
SLOT_WEIGHT = floor(Memory / 1024)
{endcode}
-Note that a job may acquire more than one of the "chunks" implied by the above policy. Again, assume the slot has 4096MB of memory, for an initial slot weight of 4. Suppose a job acquires 2048MB of that memory. Then the match will reduce the partitionable slot's weight from 4 to 2, for a match cost of 4-2=2. The submitter's usage will increase by 2. Effectively, the job has consumed 2 jobs' worth of that resource (recall that each job consumes at least one chunk of 1024), and is charged accordingly.
+Note that a job may acquire more than one of the "chunks" implied by the above policy. Again, assume the slot has 4096MB of memory, for an initial slot weight of 4. Suppose a job acquires 2048MB of that memory. Then the match will reduce the partitionable slot's weight from 4 to 2, for a match cost of 4-2=2. The submitter's usage will increase by 2.
{section: Heterogeneous Resource Models}
Consumption Policies are configurable on a per-slot basis, which makes it straightforward to support multiple resource consumption models on a single pool.
