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}
-As was mentioned above, 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 _change_ in SlotWeight.
+{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).
+
+Note that job may actually acquire more than one 'chunk' of a resource. Example: if a job ends up taking 2 of the memory quanta defined above (for 2048 mem), it will reduce the partitionable slot's weight from 4 to 2. It is effectively occupying 2 "expected jobs." and it is charged a value of 2, which is deducted against its submitter share, group quota, added to submitter usage, etc.
+
+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.
+
+For example, consider the memory-driven consumption policy above:
+{code}
+CONSUMPTION_MEMORY = quantize(target.RequestMemory, {1024})
+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.
{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.
