[slurm-users] QOS time limit tighter than partition limit

Ross Dickson ross.dickson at ace-net.ca
Thu Dec 16 22:58:28 UTC 2021


It would like to impose a time limit stricter than the partition limit on a
certain subset of users.  I should be able to do this with a QOS, but I
can't get it to work.  What am I missing?

At https://slurm.schedmd.com/resource_limits.html it says,
"Slurm's hierarchical limits are enforced in the following order ...:

1. Partition QOS limit
2. Job QOS limit
3. User association
4. Account association(s), ascending the hierarchy
5. Root/Cluster association
6. Partition limit
7. None

Note: If limits are defined at multiple points in this hierarchy, the point
in this list where the limit is first defined will be used."

And there's a little more later about the Partition limit being an upper
bound on everything.

This says to me that if:
* there is a large time limit on a partition,
* there is a smaller time limit on the job QOS, and
* the partition has no associated QOS,
then the MaxWall on the Job QOS should have effect.

But that's not what I observe.  I've created a QOS 'nonpaying' with
MaxWall=1-0:0:0, and set MaxTime=7-0:0:0 on partition 'general'.  I set the
association on  user1 so that their job will get QOS 'nonpaying', then
submit a job with --time=7-0:0:0, and it runs:

$ scontrol show partition general | egrep 'QoS|MaxTime'
   AllocNodes=ALL Default=YES QoS=N/A
   MaxNodes=UNLIMITED MaxTime=7-00:00:00 MinNodes=0 LLN=NO
MaxCPUsPerNode=UNLIMITED
$ sacctmgr show qos nonpaying format=name,flags,maxwall
      Name                Flags     MaxWall
---------- -------------------- -----------
 nonpaying                       1-00:00:00
$ scontrol show job 33 | egrep 'QOS|JobState|TimeLimit'
   Priority=4294901728 Nice=0 Account=acad1 QOS=nonpaying
   JobState=RUNNING Reason=None Dependency=(null)
   RunTime=00:00:40 TimeLimit=7-00:00:00 TimeMin=N/A
$ scontrol show config | grep AccountingStorageEnforce
AccountingStorageEnforce = associations,limits,qos

Help!?

-- 
Ross Dickson, Computational Research Consultant
ACENET  --   Compute Canada  --  Dalhousie University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schedmd.com/pipermail/slurm-users/attachments/20211216/493b6b72/attachment.htm>


More information about the slurm-users mailing list