[slurm-dev] Re: Accounting: preventing scheduling after TRES limit reached (permanently)

Jacob Chappell writes: > I should just be able to set the FairshareWeight to 0 to ignore that > component in the priority, but still enforce the limits with the > GrpMins parameters right? As Christopher Samuel wrote, you need PriorityDecayHalfLife=0 to turn of the

[slurm-dev] Re: Accounting: preventing scheduling after TRES limit reached (permanently)

Hi Douglas, Thanks for the insight. That may actually be desirable, and it's good to know that it's supported like that. I'll speak with my supervisors about what policies they are wanting giving these new details. I appreciate your all's help. Jacob Chappell On Mon, Jun 5, 2017 at 10:20 AM,

[slurm-dev] Re: Accounting: preventing scheduling after TRES limit reached (permanently)

I believe you can use fairshare without decaying usage, the fairshares will only decline over time is all. This may mean that a user that consumes a large portion of their share early may have trouble getting priority later. On Jun 5, 2017 7:10 AM, "Jacob Chappell"

[slurm-dev] Re: Accounting: preventing scheduling after TRES limit reached (permanently)

Hi Douglas, It'd be nice to have the ability to incorporate recent usage into the priority, but it seems like I can't do both that *and* have hard limits right? I think hard limits are most important between the two. I should just be able to set the FairshareWeight to 0 to ignore that component

[slurm-dev] Re: Accounting: preventing scheduling after TRES limit reached (permanently)

Sorry, I meant GrpTRESMins, but that usage is decayed, as Chris mentioned, based on the decay rate half life. In your scenario however, it seems like not decaying usage would make sense. Are you wanting to consider recent usage when making priority decisions? On Jun 5, 2017 5:53 AM, "Douglas

[slurm-dev] Re: Accounting: preventing scheduling after TRES limit reached (permanently)

I think you could still set GrpTRESRunMins on an account or association to set hard quotas. On Jun 5, 2017 5:21 AM, "Jacob Chappell" wrote: > Hi Chris, > > Thank you very much for the details and clarification. It's unfortunate > that you can't have both fairshare and

[slurm-dev] Re: Accounting: preventing scheduling after TRES limit reached (permanently)

Hi Chris, Thank you very much for the details and clarification. It's unfortunate that you can't have both fairshare and fixed quotas. I'll pass this information along to my supervisors. Jacob Chappell On Sun, Jun 4, 2017 at 7:55 PM, Christopher Samuel wrote: > > On

[slurm-dev] Re: Accounting: preventing scheduling after TRES limit reached (permanently)

On 03/06/17 07:03, Jacob Chappell wrote: > Sorry, that was a mouthful, but important. Does anyone know if Slurm can > accomplish this for me. If so how? This was how we used to run prior to switching to fair-share. Basically you set: PriorityDecayHalfLife=0 which stops the values decaying