Title: Re: [slurm-dev] Configuring multiple priority levels
What's the trade-off for using tier3? It would seem inconsiderate users would never use tier2, bypassing it completely, as there is no advantage to using it over tier3.

On 04/08//2017 17:30, Evan Remington wrote:
Configuring multiple priority levels

I'm looking for some feedback on a scheme I've come up with to configure priority tiers on our cluster which is used by a few dozen groups.

The desired behavior is that users can submit jobs to one of three priority tiers:
  • Tier 1: Lowest priority; any user can use as many resources as are available (priority subject to Fairshare).
  • Tier 2: Higher priority; users can use up to a certain amount of resources which are shared by their group.
  • Tier 3: Higher priority AND the ability to preempt jobs in Tier 1. The available resources in this tier are shared between those of Tier 2.
The way I've thought to do this is to set up three QOSs with the behavior described above (but without TRES limits), and then for each group, three corresponding accounts. The first account would only be allowed to submit to the Tier 1 QOS, the second to Tier 2, and the Third to Tier 3. Tier 2 would have GrpTRES configured, and then Tier 3 would be a child of Tier 2 and therefore share the available TRES.

Jobs would default to the Tier 1 account, going to the Tier 1 QOS. Anyone who wants to submit a higher priority job just adds --account=Tier2 or --account=Tier3.

I've tested this configuration for a single user and it seems to produce the desired result. Is there a more straightforward way to achieve the same behavior? Or is there some reason this configuration would be problematic?


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to