HTCondorWiki: Consumption Policies

 
 For example, the following is a cpu-centric resource consumption policy:
 {code}
-# cpus will generally be exhausted first
+# cpus will generally be exhausted first:
 CONSUMPTION_CPUS = target.RequestCpus
 CONSUMPTION_MEMORY = quantize(target.RequestMemory, {32})
 CONSUMPTION_DISK = quantize(target.RequestDisk, {128})
@@ -33,17 +33,17 @@
 
 Another slot might be configured with a memory-centric policy:
 {code}
-# memory will generally be exhausted first
+# memory will generally be exhausted first:
 CONSUMPTION_CPUS = 1
 CONSUMPTION_MEMORY = quantize(target.RequestMemory, {1024})
 CONSUMPTION_DISK = quantize(target.RequestDisk, {128})
 SLOT_WEIGHT = floor(Memory / 1024)
 {endcode}
 
-Note that the slot weight expression is typically configured to correspond to the "most limiting" resource, and furthermore behaves as a measure of the number of matches remaining on the partitionable slot.
+Note that the slot weight expression is typically configured to correspond to the "most limiting" resource, and furthermore behaves as a _measure of the number of potential matches remaining on the partitionable slot_.
 
 {subsubsection: Fast Slot Loading}
-
+When the HTCondor negotiator matches a job against a partitionable slot configured with a consumption policy, it will deduct the resource assets (cpu, memory, etc) from that p-slot and keep it in the list.  Therefore, a p-slot can be matched against multiple jobs in the same negotiation cycle.  This allows p-slots to be fully loaded in a single cycle, instead of matching a single job per cycle.  (Note, the CLAIM_PARTITIONABLE_LEFTOVERS feature is an alternative approach to faster p-slot loading, operating in the scheduler as opposed to the negotiator).
 
 {subsubsection: Flexible Quota Utilization}