[slurm-users] giving smaller jobs higher priority

[Satrajit Ghosh]

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.gallop at 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-bounces at lists.schedmd.com] *On
> Behalf Of *Satrajit Ghosh
> *Sent:* 22 November 2017 16:54
> *To:* slurm-users at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schedmd.com/pipermail/slurm-users/attachments/20171122/de782fcc/attachment.html>