Hi Bjørn-Helge, > On 24 Jun 2022, at 12:58, Bjørn-Helge Mevik <b.h.me...@usit.uio.no> wrote: > > Miguel Oliveira <miguel.olive...@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�vel ..." 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
smime.p7s
Description: S/MIME cryptographic signature
