That's not quite it either.  Since I couldn't find anything like this, I made a 
patch to slurm to add a MaxResvJob limit to the associations stuff, to have 
slurm not add a job to the backfill schedule map if the association has more 
than that number of running jobs.  Mostly I followed the same stuff that the 
NoReserve QOS flag does within the backfill plugin. 

I had to add stuff scattered around the source tree, including database changes 
etc. so it's a bit involved, but seems to work in my limited testing.  

This should allow for a soft "MaxJobs" by forcing all remaining jobs to only 
backfill once a user/association has reached the MaxResvJob limit. Using both 
MaxResvJobs and MaxJobs should provide similar functionality to what Moab does 
with soft/hard limits.

The git diff is a bit more than 800 lines, so I wasn't sure anyone wanted me to 
include it here.  Anyone else interested in looking at this?

-----
Gary Skouson


-----Original Message-----
From: Benjamin Redling [mailto:[email protected]] 
Sent: Thursday, February 04, 2016 12:54 PM
To: slurm-dev <[email protected]>
Subject: [slurm-dev] Re: Job limits


On 2016-02-04 16:43, Skouson, Gary B wrote:
> The GrpJobs limits the total number of jobs allowed to be running.  Let's say 
> I want to allow 70 jobs per users.  The GrpJobs would work fine for that.  

> However, I'd like to limit the number of jobs able to reserve resources in 
> the backfill schedule's map. 

sorry to not consider "fit in whatever backfill window is available" in
your first mail.

I'm I closer with:
GrpJobs/MaxJobs=70 + bf_max_job_user=<whateverfitsyourneed> ?
http://slurm.schedmd.com/sched_config.html

> Setting a QOS flag with the NoReserve does this for all jobs in the QOS, I 
> was looking for a way to only apply something like that once a user has some 
> number of running jobs.
> I'd like to force NoReserve once the user's running jobs reaches some 
> threshold.

/Benjamin
-- 
FSU Jena | JULIELab.de/Staff/Benjamin+Redling.html
vox: +49 3641 9 44323 | fax: +49 3641 9 44321

Reply via email to