On Mar 7, 2010, at 12:59 PM, Ralph Castain wrote:
> Quick question about this. We now have an OPAL level progress
thread, which enables the machinery at the OPAL level.
Unfortunately, this doesn't say anything about what the MPI level
will do?
That is correct and has always been the case. The OPAL progress
thread only indicates that opal_progress is being called via a
separate thread. Currently, turning "on" the opal progress thread
automatically turns "on" opal thread support and enables MPI thread
multiple. However, the BTLs may or may not be involved (see below).
How about calling it --enable-opal-event-progress-thread, or even --
enable-open-libevent-progress-thread?
This RFC is solely to change the configure option names to remove
the badly overloaded and confusing --enable-mpi-threads
+1
At the moment, the BTLs already use their own progress threads and
do -not- utilize the OPAL progress thread. Why the various BTL
developers chose to do this is unknown to me and essentially
irrelevant to this RFC. What the BTL developers may want to do is
review the reasons behind this design decision. As I understand it,
there was consideration of this question, and it was a made decision
(as opposed to a simple oversight) to have BTL-specific progress
threads instead of relying on the OPAL progress thread.
The openib BTL can have up to 2 progress threads (!) -- the async
verbs event notifier and the RDMA CM agent. They really should be
consolidated. If there's infrastructure to consolidate them via opal
or something else, then so much the better...
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
