hi sam, thanks for that pointer. we already have:
PriorityFavorSmall=YES PriorityFlags=SMALL_RELATIVE_TO_TIME but small jobs still seem to hold up. that's because cores more than nodes are important in our usage scenarios. 99% of jobs request one node so ideally we wanted to assign negative weights to TRES but that didn't work for priority. cheers, satra On Wed, Nov 22, 2017 at 12:13 PM, Sam Gallop (NBI) <sam.gal...@nbi.ac.uk> wrote: > Hi Satra, > > > > Have a look at PriorityFavorSmall (in slurm.conf). It may fit your needs. > Not used it myself, so I'm not able to say if it'll do exactly what you're > after. > > > > *---* > > *Samuel Gallop* > > > > *From:* slurm-users [mailto:slurm-users-boun...@lists.schedmd.com] *On > Behalf Of *Satrajit Ghosh > *Sent:* 22 November 2017 16:54 > *To:* slurm-users@lists.schedmd.com > *Subject:* [slurm-users] giving smaller jobs higher priority > > > > slurm has a way of giving larger jobs more priority. is it possible to do > the reverse? > > > > i.e., is there a way to configure priority to give smaller jobs (use less > resources) higher priority than bigger ones? > > > cheers, > > satra > > resources: can be a weighted combination depending on system resources > available: > > > > w1*core + w2*memory + w3*time + w4*gpu > > > > where core, memory, time, gpu are those requested by the job, and w1-4 are > determined by system resources/group allocations. >
