<html><body><div style="font-family: trebuchet ms,sans-serif; font-size: 11pt; color: #000000"><div>Hi Ole and B/H,<br><br>Thanks for your answers.<br></div><div><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>You're right B/H, and as I tuned <strong>TRESBillingWeights</strong> option to only counts cpu, in my case : <!--StartFragment-->nb of reserved core <strong>= </strong> <!--StartFragment-->"TRES billing cost" <!--EndFragment--> <!--EndFragment--> </div><div><br data-mce-bogus="1"></div><div>You're right again I forgot the <strong>PriorityDecayHalfLife</strong> parameter which is also used by fairshare <strong>Multifactor Priority.</strong><!--StartFragment--><!--EndFragment--> <br>We use multifactor priority to manage the priority of jobs in the queue, and we set the values of <strong>PriorityDecayHalfLife</strong> and <strong>PriorityUsageResetPeriod</strong> according to these needs.<br>So <!--StartFragment--><em><strong>PriorityDecayHalfLife</strong></em> <!--EndFragment-->will decay <strong>GrpTRESRaw</strong><!--EndFragment--> and <!--StartFragment-->GrpTRESMins <!--EndFragment--> can't be used as we want.<br><br>Setting <!--StartFragment--><em>the <strong>NoDecay</strong> flag</em><!--EndFragment--> to a QOS could be an option but I suppose it also impact fairshare <strong>Multifactor Priority</strong> of all jobs using this QOS<strong>.</strong></div><div><strong><br data-mce-bogus="1"></strong></div><div>This means I have no solution to limit a project as we want, unless schedMD changes its behavior or adds a new feature.<!--EndFragment--> <!--EndFragment--> <br><br>Thanks a lot.<br><br>Regards, <br>Gérard<span style="color: #3333ff;"><br></span><a href="http://www.cines.fr" target="_blank"></a><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>De: </b>"Bjørn-Helge Mevik" <b.h.mevik@usit.uio.no><br><b>À: </b>slurm-users@schedmd.com<br><b>Envoyé: </b>Jeudi 23 Juin 2022 12:39:27<br><b>Objet: </b>Re: [slurm-users] GrpTRESMins and GrpTRESRaw usage<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"> Ole Holm Nielsen <Ole.H.Nielsen@fysik.dtu.dk> writes:<br> <br><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"> Hi Bjørn-Helge,</blockquote><br> <br> Hello, Ole! :)<br> <br><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"> On 6/23/22 09:18, Bjørn-Helge Mevik wrote:<br><br><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"> Slurm the same internal variables are used for fairshare calculations as<br> for GrpTRESMins (and similar), so when fair share priorities are in use,<br> slurm will reduce accumulated GrpTRESMins over time. This means that it<br> is impossible(*) to use GrpTRESMins limits and fairshare<br> priorities at the same time.</blockquote><br><br> This is a surprising observation!</blockquote><br> <br> I discovered it quite a few years ago, when we wanted to use Slurm to<br> enforce cpu hour quota limits (instead of using Maui+Gold). Can't<br> remember anymore if I was surprised or just sad. :D<br> <br><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"> We use a 14 days HalfLife in slurm.conf:<br> PriorityDecayHalfLife=14-0<br><br> Since our longest running jobs can run only 7 days, maybe our limits<br> never get reduced as you describe?</blockquote><br> <br> The accumulated usage is reduced every 5 minutes (by default; see<br> PriorityCalcPeriod). The reduction is done by multiplying the<br> accumulated usage by a number slightly less than 1. The number is<br> chosen so that the accumulated usage is reduced to 50 % after<br> PriorityDecayHalfLife (given that you don't run anything more in<br> between, of course). With a halflife of 14 days and the default calc<br> period, that number is very close to 1 (0.9998281 if my calculations are<br> correct :).<br> <br> Note: I read all about these details on the schedmd web pages some years<br> ago. I cannot find them again (the parts about the multiplication with<br> a number smaller than 1 to get the half life), so I might be wrong on<br> some of the details.<br> <br><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"> BTW, I've written a handy script for displaying user limits in a<br> readable format:<br> https://github.com/OleHolmNielsen/Slurm_tools/tree/master/showuserlimits</blockquote><br> <br> Nice!<br> <br> --<br> B/H<br><br></blockquote></div></div></body></html>