Danny is correct with respect to partition-based preemption rules. You can specify the preemption mechanism used for each partition, but they are enforced using a simple ordering by priority. QOS-based preemption is much more flexible, but requires the use of a slurmdbd (database daemon and database). ________________________________________ From: [email protected] [[email protected]] On Behalf Of Danny Auble [[email protected]] Sent: Thursday, May 12, 2011 7:53 AM To: [email protected] Subject: Re: [slurm-dev] Complex configuration of partition preemption?
Hey Daniel, > Hi, > > Two Questions: > 1. I would like to ask you if it is possible to create the next kind of > configuration: > > PARTITION-1 priority=90 > PARTITION-2 priority=50 > PARTITION-3 priority=10 > > What I want to get here is that PARTITION-1 can preempt any of PARTITION-2 > or PARTITION-3. But PARTITION-2 must not be able to preempt partition-3. > > Any clues on how to get this setup, previously I tried to use something > like: > > PARTITION-3 PreemptMode=suspend > > But that of course causes that PARTITION-3 can be preempted by any of the > other two partitions. I don't think you can do this with the partition priority, but this kind of thing will work with QOS. You might give that a try. It will give you a bunch more flexibility as well. > > 2. Is there any sacctmgr way to limit the total consumed wall-time? Some new > users will be added to our cluster, but we want to add these new accounts > with a limit on total wall-time usage, then when the user/group reach the > limit we want to prevent it from executing more jobs. Is it possible to do > this with slurm? GrpWall. If you use that on a user association the group will just be that one user, so all their jobs will aggregate together. If you use it on an account all the user accounts inside that account and all its subaccounts will be aggregated. You have to use the priority/multifactor plugin to make it work. see man sacctmgr Danny > > > Thanks, > Daniel >
