From past customer reports the problem with preempt_sort is that there is only one “sort”, might it be better to just fix the problem with what happens when it is unset (make “least time since start” the default when unset) and then add other sorting options? For example, by priority (formula?), by user, chkpt jobs first, etc.
What were the customers trying to achieve with alternate proposed preempt_sort values? Priority and user are already baked in (in a way) via preempt_prio choosing which jobs can be preempted.
The first level sort is on preemption priority (based on preempt_prio). This is required because we don’t want to preempt a job just to have it preempt something else later in the cycle to run. Within a preemption level we sort on min time since start.
If we were to do a formula, what would the resources mean? In the job sort formula, we used requested resources. In the fairshare formula we use the used resources. What would make sense for a preemption formula? Unused (Resource_List - resources_used)?
checkpoint jobs first doesn’t make a huge amount of sense because we don’t specifically know how a job will be preempted. We get a list of SCRD which will decide that based on what works. We know if checkpoint is the first one in the list, but it might fail and we fallback to something else.
@smgoosen From the above conversation it seems that preempt_sort attribute does not serve any purpose and therefore we should remove it. Let me know what you think otherwise
This task has been shelved. It might turn out that we require prempt_sort attribute in future so keeping the it for now. The only value that will be assigned to preempt_sort is min_time_since_start. It will not be possible to UNSET the attribute. On UNSET the value will remain min_time_since_start.
I have updated the design to reflect that.