Sure:
$ ompi_info --param hwloc all -l 9
…..
MCA hwloc: parameter "hwloc_base_cpu_set" (current value: "",
data source: default, level: 9 dev/all, type:
string)
Comma-separated list of ranges specifying lo
Thank you and one last question. Is it possible to avoid a core and
instruct OMPI to use only the other cores?
On Mon, Dec 22, 2014 at 2:08 PM, Ralph Castain wrote:
>
> On Dec 22, 2014, at 10:45 AM, Saliya Ekanayake wrote:
>
> Hi Ralph,
>
> Yes the report bindings show the correct binding as ex
> On Dec 22, 2014, at 10:45 AM, Saliya Ekanayake wrote:
>
> Hi Ralph,
>
> Yes the report bindings show the correct binding as expected for the
> processes. The doubt I am having is, say I spawn a thread within my process.
> If I don't specify affinity for it, is it possible for it to get sche
Hi Ralph,
Yes the report bindings show the correct binding as expected for the
processes. The doubt I am having is, say I spawn a thread within my
process. If I don't specify affinity for it, is it possible for it to get
scheduled to run in a core outside that of the process?
Second question is,
FWIW: it looks like we are indeed binding to core if PE is set, so if you are
seeing something different, then we may have a bug somewhere.
If you add —report-bindings to your cmd line, you should see where we bound the
procs - does that look correct?
> On Dec 22, 2014, at 9:49 AM, Ralph Casta
They will be bound to whatever level you specified - I believe by default we
bind to socket when mapping by socket. If you want them bound to core, you
might need to add —bind-to core.
I can take a look at it - I *thought* we had reset that to bind-to core when
PE=N was specified, but maybe tha
Hi,
I've been using --map-by socket:PE=N, where N is used to control the number
of cores a proc gets mapped to. Does this also guarantee that a proc is
bound to N cores in the socket? I am asking this because I see some threads
spawned by the process run outside the given N cores in the socket.
I
