On a side note, I have a minor documentation bug report: On this page http://slurm.schedmd.com/cpu_management.html there is a link to
-s, --oversubscribe which points to http://slurm.schedmd.com/srun.html#OPT_share The actual link is http://slurm.schedmd.com/srun.html#OPT_oversubscribe cheers L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper On 22 September 2016 at 14:51, Lachlan Musicman <[email protected]> wrote: > Our nodes have > > Sockets=2 CoresPerSocket=10 ThreadsPerCore=2 > > CPUs are set to 40 and SelectTypeParameters=CR_CPU > > According to this FAQ, this is "not a typical configuration". > > http://slurm.schedmd.com/faq.html#cpu_count > > Which is fine, I am aware that this is the set up - I did the > configuration. > > One of our users is complaining that we don't have the regular set up with > a "cpu=core" rather than a "cpu=thread". > > In reality, a large majority of our users run non thread aware > bioinformatics software, so I am ok with our current set up - most of our > jobs are largely parallel. > > Since changing to cpu=core setup would halve our resources, unless I could > convince or remind people to use srun --shared (according to > http://slurm.schedmd.com/cons_res_share.html ) > > Alternatively OverSubscribe=FORCE would solve that problem of lazy/greedy > users, but doesn't that then override any advantage a hyperthreaded > software might have? > > What are the nuances between the set up we have, and using OverSubscribe=X > with cpu=core (given that core=2 threads)? > > Would there be a performance benefit from making cpu=core and halving the > available processes - would the halved number of processes run/finish > faster making up for the loss of flexibility? > > Cheers > L. > > > ------ > The most dangerous phrase in the language is, "We've always done it this > way." > > - Grace Hopper >
