Thanks Don for the clarification. I had thought based on the documentation that somehow the PriorityUsageResetPeriod option was enforcing a limit which wasn't congruent with my understanding of SLURM's limit enforcement.
-Aaron On Tue, May 10, 2011 at 1:28 PM, Lipari, Don <[email protected]> wrote: > Aaron, > > > > To enable a hard limit to an association’s daily usage, you are correct in > setting PriorityUsageResetPeriod=DAILY and PriorityDecayHalfLife=0. However > the limit itself is set by the association’s GrpWall setting, not its > shares. Also, you’ll need to confirm the following also appears in your > slurm.conf file: > > > > AccountingStorageEnforce=limits > > > > Don > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Aaron Knister > *Sent:* Tuesday, May 10, 2011 9:04 AM > *To:* slurm-dev > *Subject:* [slurm-dev] PriorityUsageResetPeriod question > > > > Regarding the the PriorityUsageResetPeriod option: My take on the > documentation for it [1] is that if it's set it and PriorityDecayHalfLife is > set to 0 jobs of users who have exceeded their fair share won't run. Is that > the case or am I misunderstanding it? I've been doing some testing with > PriorityUsageResetPeriod=DAILY and PriorityDecayHalfLife=0 and I can't find > a scenario in which a user's job won't run. I've even tried setting a user's > fair share to 0 their jobs still run. This is actually the behavior I'm > looking for but I want to make sure I correctly understand the option. I am > running 2.1.10 which I know is old (there are plans to upgrade in the near > future) so that may well be the problem. > > > > [1]- "By default this is turned off and it is advised to use the > PriorityDecayHalfLife option to avoid not having anything running on your > cluster, but if your schema is set up to only allow certain amounts of time > on your system this is the way to do it. " > > > > Thanks! > > > > -Aaron >
