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

Re: [HTCondor-users] Configuring NEGOTIATOR_PRE_JOB_RANK and NEGOTIATOR_POST_JOB_RANK to optimize matching



On 3/13/19 11:31 AM, Lars Henrik Sowa wrote:

Hi all,

 


Currently I do not understand why Memory is in there with a negative sign. According to the documentation memory is “The amount of RAM in MiB in this slot. For static slots, this value will be the same as in TotalSlotMemory. For a partitionable slot, this value will be the quantity remaining in the partitionable slot.”. In our case this is equal to TotalSlotMemory as well as TotalMemory as we only have one slot per machine. However if I understood this correctly this would mean that with the default value, NEGOTIATOR_PRE_JOB_RANK would prefer machines with less memory over ones with more memory. Is this correct? If I now actually want to match machines with more memory first I just would have to turn the – memory into a + memory?


The idea for the negative signs in front of the memory and cpu, is this:  Typically a job requests at least a certain amount of memory and cores.  Given there may be many slots which match a given job, the smallest one that meets the request leaves larger slots available for other jobs which may require more.  When the negotiator run, it examines one job at a time (from the user with the best user priority).  The negotiator doesn't know anything about any other jobs that might be coming next, so this policy tries to minimize resource fragmentation.


-greg