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

-s, --oversubscribe

which points to


The actual link is



The most dangerous phrase in the language is, "We've always done it this

- Grace Hopper

On 22 September 2016 at 14:51, Lachlan Musicman <data...@gmail.com> 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

Reply via email to