Yep, we get 40 CPUs. That's why I answered as I did to your thread :) L.
------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper On 22 September 2016 at 17:06, andrealphus <andrealp...@gmail.com> wrote: > > wait, out of curiosity; > > "Sockets=2 CoresPerSocket=10 ThreadsPerCore=2 > CPUs are set to 40 and SelectTypeParameters=CR_CPU" > > this is actually allowing you to run 40 processes? When I tried it, it > showed 40 available cpus, but would only allocate at the core level, > not thread level, and hence was a hard limit of 20. > > On Wed, Sep 21, 2016 at 9:54 PM, Lachlan Musicman <data...@gmail.com> > wrote: > > 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 <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 > > > > >
