I have never really understood the approach of having different
partitions for different lengths of job, but it seems to be quite
widespread, so I assume there are valid use cases.

However, for our around 450 users, of which about 200 will submit at
least one job in a given month, we have an alternative approach without
pre-emption where we essentially have just a single partition.  Users
can then specify a QOS which will increase priority at the cost of
accepting a lower cap on number of jobs/resources/maximum runtime:

$ sqos
      Name   Priority     MaxWall MaxJobs MaxSubmit            MaxTRESPU 
---------- ---------- ----------- ------- --------- -------------------- 
    hiprio     100000    03:00:00      50       100   cpu=128,gres/gpu=4 
      prio       1000  3-00:00:00     500      1000   cpu=256,gres/gpu=8 
  standard          0 14-00:00:00    2000     10000  cpu=768,gres/gpu=16 

where

  alias sqos='sacctmgr show qos format=name,priority,maxwall,maxjobs,maxsubmitjobs,maxtrespu%20'
          /usr/bin/sacctmgr

The standard cap on the resources corresponds to about 1/7 of our cores.

The downside is that very occasionally nodes may idle because a user has
reached his or her cap.  However, we have usually have enough uncapped
users submitting jobs, so that in fact this happens only rarely, such as
sometimes at Christmas or New Year.

Cheers,

Loris

Hi Loris, Tomas

I'm new too in using slurm shceduler.

In your configuration, you have to define a DefaultQOS for each User, or Association, right? You don't defina DefaultQOS at partition nivel..

Thank's!

-- 
-- Jérôme 
L'amour, c'est comme le potage : les premières cuillerées sont trop chaudes, 
les dernières sont trop froides.
    (Jeanne Moreau)