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
+{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:
