MY.IsWholeMachineSlot =!= True && $(WHOLE_MACHINE_SLOT_STATE) =?= "Claimed" )
{endcode}
+Another possible policy is to suspend the whole machine job if there are any single core jobs but to kick the single-core jobs off if they take too long to finish. Starting with the original example policy, this can be achieved by adding the following to the configuration:
+
+{code}
+PREEMPT = ($(PREEMPT)) || ( \
+ MY.IsWholeMachineSlot =!= True && $(WHOLE_MACHINE_SLOT_STATE) =?= "Claimed" )
+
+# When a job is preempted, let it run for up to a day before killing it
+MaxJobRetirementTime = 24*3600
+{endcode}
+
{subsection: Accounting}
The above policies rely on job suspension. Should the jobs be "charged" for the time they spend in a suspended state? This affects the user's fair-share priority and the accumulated number of hours reported by condor_userprio. As of Condor 7.4, the default behavior is to charge the jobs for time they spend in a suspended state. There is a configuration variable, NEGOTIATOR_DISCOUNT_SUSPENDED_RESOURCES that can be used to get the opposite behavior.
+
+Should the whole-machine slot charge more than the single-core slots? The policy for this is determined by =SlotWeight=. By default, this is equal to the number of cores associated with the slot, so usage reported in condor_userprio will count the whole-machine slot on an 8-core machine as 8 times the usage reported for a single-core slot.
