Massimo, Slurm sometimes takes into account things in a surprising way. While debugging the issue, in addition to what Loris said, I suggest that you also check the accounts (which should have been called groups, but I digrees) and associations, to see if they got in the way or what should have been happening Cheers On Fri, Jul 10, 2026 at 8:26 AM Loris Bennett via slurm-users < slurm-users@lists.schedmd.com> wrote:
Hi Massimo,
Massimo Sgaravatto via slurm-users <slurm-users@lists.schedmd.com> writes:
Dear all
I have these settings in slurm.conf:
. ... PreemptType=preempt/partition_prio PreemptMode=REQUEUE
PartitionName=gpus-opp Nodes=btc-ter-gpu-[03-05],btc-dfa-gpu-06,btc-dfa-gpu-02 State=UP PriorityTier=15 PartitionName=mpicms Nodes=btc-ter-03,btc-ter-gpu-05 AllowAccounts=cms,operators State=UP PriorityTier=20
....
My understanding was that the expected behavior is that a job submitted to the gpus-opp partition is always preempted (requeued) if the resources allocated by this job are requested by a job submitted to the mpicms partition (since 20 > 15)
Did I get it right?
I am asking because I see that sometimes this doesn't happen. I am still trying to debug the issue, but it looks like also the QoS is taken into account (and this doesn't make sense to me unless I am missing something)
Here
https://slurm.schedmd.com/qos.html#preemption
it says
Partition QOS
A QOS can be attached to a partition. This means the partition will have all the same limits as the QOS. This does not associate jobs with the QOS, nor does it give the job any priority or preemption characteristics of the assigned QOS. Jobs may separately request the same QOS or a different QOS to gain those characteristics. However, the Partition QOS limits will override the job's QOS. If the opposite is desired you may configure the job's QOS with Flags=OverPartQOS which will reverse the order of precedence.
Is that relevant?
Cheers,
Loris
-- Dr. Loris Bennett (Herr/Mr) FUB-IT, Freie Universität Berlin
-- slurm-users mailing list -- slurm-users@lists.schedmd.com To unsubscribe send an email to slurm-users-leave@lists.schedmd.com