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