Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: Rename --enable-*-threads and ENABLE*THREAD*(take 2)
From: Ralph Castain (rhc_at_[hidden])
Date: 2010-03-07 23:13:46


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
> jsquyres_at_[hidden]
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel