[slurm-users] GrpTRESMins and GrpTRESRaw usage

Miguel Oliveira miguel.oliveira at uc.pt
Fri Jun 24 12:46:31 UTC 2022


Hi Bjørn-Helge,

> On 24 Jun 2022, at 12:58, Bjørn-Helge Mevik <b.h.mevik at usit.uio.no> wrote:
> 
> Miguel Oliveira <miguel.oliveira at uc.pt> writes:
> 
>> Hi Bjørn-Helge,
>> 
>> Long time!
> 
> Hi Miguel!  Yes, definitely a long time!  :D

Indeed!

> 
>> Why not? You can have multiple QoSs and you have other techniques to change priorities according to your policies.
> 
> A job can only run in a single QoS, so if you submit a job with "sbatch
> --qos=devel ..." it will no longer be running in the account QoS and
> thus its usage will not be recorded in that QoS.  If that is ok, then no
> problem, but if you want all jobs of an account to be limited by the
> TRESMins limit, then you cannot use other QoS'es than the account QoSes
> (except for partition QoSes).

Unfortunately my cluster is down (storage issues ….) so I cannot test yet! The limit would certainly be imposed as, and I quote from documentation,
"If limits are defined at multiple points in this hierarchy, the point in this list where the limit is first defined will be used" (as long as job QoS does not define a different limit as this one takes precedence).
You are very likely right that slurm would not decrease the usage counter on the original account QoS in your scenario.
In that case then you can give every project a different development allocation to use! Your purpose was to limit project allocations anyway!!!

Even if that is not your thing, as I said originally,  you have other techniques to change priorities or limits. In the case of development work, you could in principle define a development partition and enforce priorities and limits at that level.

All these are not really a replacement for proper allocation management, like gold was!!! But it does the trick!

Best,

MAO



> 
> -- 
> Bjørn-Helge

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4243 bytes
Desc: not available
URL: <http://lists.schedmd.com/pipermail/slurm-users/attachments/20220624/908f6f9b/attachment-0002.bin>


More information about the slurm-users mailing list