Hi Todd, On 18/06/2021 21.53, Todd L Miller wrote:
ÂÂÂÂI don't understand what your example.Â What do the previous set of jobs have to do with the cost of draining?Â Isn't the cost of draining just the slot-weight of the slots idled by draining times the duration of that idling?Â (Assuming you neither preempt to drain nor run backfill jobs while draining.)
background are grid pilot jobs, which normally do not come in with a reasonable run time request, so that backfilling is not that easy. The other thing is, that sometimes some users switch from single to multi core tasks, that trigger slots to be drained all over the cluster. Since the "loss" of the unused slots during draining is not passed through to the users and since their is no good pilot/payload runtime estimate, there is no real initiative for the users to optimize their s/mcore usage patterns - as the draining costs are not accounted for.
So, I had been thinking, if there might be a way, to pass the costs of unused slots during draining through to the initiator of the mcore-slot-to-be?
Description: S/MIME Cryptographic Signature