Mailing List Archives
Authenticated access
|
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HTCondor-users] Group Quotas and Preemption
- Date: Mon, 20 Jan 2014 12:09:14 -0500 (EST)
- From: Erik Erlandson <eje@xxxxxxxxxx>
- Subject: Re: [HTCondor-users] Group Quotas and Preemption
----- Original Message -----
>
> So, in essence, you rely on artificially tweaking user priorities to trigger
> preemption, while I would like it to occur whenever actual usage is not
> according to the group quotas.
Getting exactly that behavior may not be possible, because job preemption cannot happen until a submitter's priority-value drops below the priority of the submitter currently occupying the slot. That logic is hard-coded:
https://github.com/htcondor/htcondor/blob/master/src/condor_negotiator.V6/matchmaker.cpp#L4182
It is possible to alter the rate at which prio-values evolve, by reconfiguring PRIORITY_HALFLIFE:
http://research.cs.wisc.edu/htcondor/manual/v8.0/2_7Priorities_Preemption.html#3753
That can at least reduce the latencies of waiting for priority values to become favorable for preemption.
Another possible approach would be to configure similar quota-preserving clauses onto the slot rank preemption, which is not contingent on priority values:
http://research.cs.wisc.edu/htcondor/manual/v8.0/3_5Policy_Configuration.html#29522
However, to obtain a global policy in that way, the RANK expression would have to be applied to every slot. possibly a job for wallaby:
http://getwallaby.com/
I have another post that is not probably not directly applicable to your problem, but does demonstrate per-slot RANK configurations:
http://erikerlandson.github.io/blog/2012/07/10/configuring-minimum-and-maximum-resources-for-mission-critical-jobs-in-a-condor-pool/