<div dir="ltr"><div>Hi All,</div><div><br></div><div>  I'm trying out using GrpTRESRunMins to prevent users from opportunistically flooding an empty partition with long jobs. We have a partition set up for each CPU type, and give each association (account/user/partition) a separate limit based on that account's share of the partition.</div><div><br></div><div>  It seems to work as expected, except when a job is submitted to multiple partitions. We had a few jobs getting blocked because only one partition would be over the limit. The blocking partition was alphabetically first, so I'm guessing that the GrpTRESRunMins check doesn't attempt to look at the others after one fails.</div><div><br></div><div>  This is with slurm 17.11.4. I haven't dug around in the code, but didn't see relevant changes in the changelog for 17.11.6. </div><div><br></div><div>  It's being used as a secondary backstop for abuse, so the limits aren't hit often, but suggestions for a fix/work-around would be welcome!</div><div><br></div><div>Thanks,</div><div>Nate</div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><pre>Dr. Nathan Crawford              <a href="mailto:nathan.crawford@uci.edu" target="_blank">nathan.crawford@uci.edu</a>
Modeling Facility Director
Department of Chemistry
1102 Natural Sciences II         Office: 2101 Natural Sciences II
University of California, Irvine  Phone: 949-824-4508
Irvine, CA 92697-2025, USA</pre></div></div>
</div>