Hi all; As I posted in my previous email, I am having problems to understand Slurm's behaviour when using suspend/resume. The bellow configuration works fine and Slurm suspends the precise amount of low priority jobs when a high priority job is submitted.
FastSchedule=2 SchedulerType=sched/backfill SelectType=select/linear #SelectType=select/cons_res #SelectTypeParameters=CR_CPU PreemptMode=SUSPEND,GANG PreemptType=preempt/partition_prio However, when I change this configuration to use consumable resources: #SelectType=select/linear SelectType=select/cons_res SelectTypeParameters=CR_CPU Slurm suspends more than necessary low priority jobs, which leads to a sub utilisation of the cluster. Would be this a problem of configuration, or a problem in the select plugin? Thanks, Claudio On Thu, Feb 2, 2017 at 2:43 PM, Claudio <[email protected]> wrote: > Hi all; > > I setup a Slurm based cluster to study scheduling algorithms. This cluster > has 10 nodes and 2 CPUs per node. I compiled Slurm with the > "--enable-multiple-slurmd" option and I configured it to act as a 3600 > node cluster with 16 CPUs per node. Since I am only submitting sleep jobs, > this configuration seems to work just fine. > > However, I am getting a very odd behaviour when using suspend-resume. When > suspending low priority jobs to run a higher priority job, Slurm is > suspending roughly twice the number of CPUs necessary to run this high > priority job. > > Does anyone have any idea why is this happening? > > Thank you very much. > > Best regards, > Claudio > >
