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
> >
> >
>

Reply via email to