This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
On 12/8/12 7:59 PM, "Ralph Castain" <rhc_at_[hidden]> wrote:
>WHAT: Enable both OPAL and libevent thread support by default
>WHY: We need to support threaded operations for MPI-3, and for
> Enabling thread support by default is the only way to
>ensure we fix all the problems.
>WHEN: COB, Thurs Dec 13
>This was a decision reached at the OMPI Developers meeting, so the RFC is
>mostly just a "heads up" to everyone that this will happen. We spent some
>time recently profiling the impact on performance and found it to be
>significant: 100ns in shared memory latency, and a similar number to TCP
>message latency. However, without setting the support "on" by default, we
>will never address those problems. Thus, the group decided that we would
>enable support by default and being a concerted effort to reduce and/or
>remove the performance impact.
Thinking about this on the way home Friday, I'm not sure we need to go
quite that far. I think we do want to enable MPI_THREAD_MULTIPLE by
default to cause all the locks to be "on" by default. I'm not sure we
need to enable progress threads at this point; the question is do we want
to take a top-down approach, where we turn on the locks all the time for
everything (expensive) and pare down what actually needs locking for async
btl callbacks or do we leave off all the locking by default (when thread
count == 1) and only turn on always-lock locks for the code paths that
will deal with async callbacks from the BTLs. I'm split on the issue.
Brian W. Barrett
Scalable System Software Group
Sandia National Laboratories