[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HTCondor-users] Filling pool breadth-first with partitionable slots



When negotiating without CONSUMPTION_POLICY, and with CLAIM_PARTITIONABLE_LEFTOVERS=false

When the negotiator matches a job with a partitionable slot, it gives the whole slot to the schedd,  The

SCHEDD then activates the claim by contacting the STARTD and that splits off a dynamic slot. 

The partitionable slot, now reduced in size (the leftovers) is sent to the collector to be fetched on

The next negotiation cycle and the process repeats.

 

When CLAIM_PARTITIONABLE_LEFTOVERS=true,  when the SCHEDD activates itâs claim on the partitionable

Slot, that  splits off a dynamic slot, and the STARTD gives the SCHEDD back a new claim id for the remainder of the partitionable slot (the leftovers).  The SCHEDD will then try and use the new claim with another job.  This continues until the partitionable slot is exhausted or until the SCHEDD runs out of idle jobs that match that slot.

 

But there is a race condition,  while the SCHEDD is claiming the partitionable leftovers, they are ALSO sent to the collector and may be handed out to another SCHEDD in another negotiation cycle.  The two SCHEDDs will race to see which can activate the claim first, the first to claim wins, and the has their claim rejected.

 

-tj

 

From: HTCondor-users [mailto:htcondor-users-bounces@xxxxxxxxxxx] On Behalf Of Tom Downes
Sent: Tuesday, November 8, 2016 9:39 AM
To: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx>
Subject: Re: [HTCondor-users] Filling pool breadth-first with partitionable slots

 

On Wed, Nov 2, 2016 at 12:03 PM, John M Knoeller <johnkn@xxxxxxxxxxx> wrote:

 

COMSUMPTION_POLICY moves partitionable slot splitting into the negotiator.  Otherwise the splitting of the partitionable slot happens in the STARTD as part of the process of the SCHEDD claiming a slot.  (which is why you can only do one per cycle)

 

I understand that. The entry for this macro in the manual (p. 251 in manual 8.5.7) should say that.

 

 The upside of this is that the negotiator can then choose breadth first or depth first without any effect negotiation efficiency. 

But the negotiator is also doing more work, so the overall negotiation cycle takes longer.  

 

I think you mean scheduler efficiency?

 

Can you explain what, exactly, it is that CLAIM_PARTITIONABLE_LEFTOVERS is doing? How do the leftovers rank compared to other matches?

 

Tom