Beautiful! Thanks.
Not the way that I'd like it implemented in my case but good to have it
clarified.
Bill
On 9/24/2015 7:00 PM, Moe Jette wrote:
That was not described very well. I've updated the web page, which
should clarify this.
Quoting Bill Wichser <[email protected]>:
For some reason I struggle with limits. Somehow I've learned that
limits can be applied to accounts with the "grp" limits and to users
themselves with the "max" limits though never have really found this
documented very well.
And once again I am trying to determine who wins when various "max"
limits are set.
On the page
http://slurm.schedmd.com/resource_limits.html
under Hierarchy, is the statement
Note: Higher precedent limits override lower.
My interpretation of this is completely different than my colleague
here, which is nothing unusual! I read this as
The policy goes down the list starting at #1 Partition QOS. It
continues moving down through and if there is an override, it wins.
An example here would be worthwhile and I'll offer one which may or
may not be correct.
Lets assume that I have a QOS with a maxjobs=20. Assume further that
I have a user with maxjobs=2. When it comes down to actually
scheduling, the job fits the QOS spec. But further down the list,
when we get to #4, we find that the limit is 2 and thus this becomes
the new limiting factor.
Is this the correct interpretation?
The final goal here is to have a fairly lenient policy but have the
ability to penalize certain users who abuse the system.
Thanks,
Bill
