David WALTER <[email protected]> writes: > Dear Loris, > > Thanks for your response ! > > I'm going to look on this features in slurm.conf. I only configured > the CPUs, Sockets.... per node. Do you have any example or link to > explain me how it's working and what can I use ?
It's not very complicated. A feature is just a label, so if you had some nodes with Intel processors and some with AMD, you could attach the features, e.g. NodeName=node[001,002] Procs=12 Sockets=2 CoresPerSocket=6 ThreadsPerCore=1 RealMemory=42000 State=unknown Feature=intel NodeName=node[003,004] Procs=12 Sockets=2 CoresPerSocket=6 ThreadsPerCore=1 RealMemory=42000 State=unknown Feature=amd Users then just request the required CPU type in their batch scripts as a constraint, e.g: #SBATCH --constraint="intel" > My goal is to respond to people needs and launch their jobs as fast as > possible without losing time when one partition is idle whereas the > others are fully loaded. The easiest way to avoid the problem you describe is to just have one partition. If you have multiple partitions, the users have to understand what the differences are so that they can choose sensibly. > That's why I thought the fair share factor was the best solution Fairshare won't really help you with the problem that one partition might be full while another is empty. It will just affect the ordering of jobs in the full partition, although the weight of the partition term in the priority expression can affect the relative attractiveness of the partitions. In general, however, I would suggest you start with a simple set-up. You can always add to it later to address specific issues as they arise. For instance, you could start with one partition and two QOS: one for normal jobs and one for test jobs. The latter could have a higher priority, but only a short maximum run-time and possibly a low maximum number of jobs per user. Cheers, Loris -- Dr. Loris Bennett (Mr.) ZEDAT, Freie Universität Berlin Email [email protected]
