On Mar 7, 2010, at 5:13 PM, Jeff Squyres wrote: > 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?
Why not add another 100+ characters to the name while we are at it? :-/ enable-opal-progress-thread accurately reflects what it does, IMHO > >> 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... Agreed, though I think that is best done as a separate effort from this RFC. I believe there was a concern over latency if all the BTLs are driven by one progress thread that sequentially runs across their respective file descriptors, but I may be remembering it incorrectly... > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
