*Ack* you're correct. This was a recent, hastily added feature to control budgets on our system. I need to re-evaluate our approach. As you mentioned, the QOS GrpTRESMins limits appear to be the only NoDecay option. Managing them will be challenging on our system because they'll be numerous...
The behavior of the NoDecay QOS option is clearly described in docs. I'm not sure why I interpreted it so incorrectly! Decay has served us well, and I'd like to keep it around. Please let me know if you discover an efficient configuration that works for you. Thanks, Sebastian -- [University of Nevada, Reno]<http://www.unr.edu/> Sebastian Smith High-Performance Computing Engineer Office of Information Technology 1664 North Virginia Street MS 0291 work-phone: 775-682-5050<tel:7756825050> email: stsm...@unr.edu<mailto:stsm...@unr.edu> website: http://rc.unr.edu<http://rc.unr.edu/> ________________________________ From: slurm-users <slurm-users-boun...@lists.schedmd.com> on behalf of Yair Yarom <ir...@cs.huji.ac.il> Sent: Monday, November 23, 2020 4:21 AM To: Slurm User Community List <slurm-users@lists.schedmd.com> Subject: Re: [slurm-users] NoDecay on accounts (or on GrpTRESMins in general) On Fri, Nov 20, 2020 at 12:11 AM Sebastian T Smith <stsm...@unr.edu<mailto:stsm...@unr.edu>> wrote: Hi, We're setting GrpTRESMins on the account association and have NoDecay QOS's for different user classes. All user associations with a GrpTRESMins-limited account are assigned a NoDecay QOS. I'm not sure if it's a better approach... but it's an option. If I follow correctly, your GrpTRESMins usage on the accounts will still get decayed. From tests I ran here when running with a NoDecay QOS, the GrpTRESMins of the account still gets decayed, while the GrpTRESMins of the QOS doesn't. So do you also have a GrpTRESMins on the QOS itself? And if so, why do you need both on the QOS and on the account? or am I missing something? Thanks, Yair.
