Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

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.

Subject: Re: [OMPI devel] RFC: Rename --enable-*-threads andENABLE*THREAD*(take 2)
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2010-03-08 08:43:44

On Mar 7, 2010, at 8:13 PM, Ralph Castain wrote:

> > 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? :-/


I didn't really think the length mattered here, since it's a configure
argument. There has been a *lot* of confusion over the name of this
particular switch over the past few years, so I'm suggesting that a
longer, more descriptive name might be a little better. Just my

> > 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.

Agreed -- sorry, I wasn't clear. I wasn't trying to propose that that
work be added to this RFC; I was just trying to mention that there
could be a good use for the work from this RFC if such infrastructure
was provided.

> 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...

FWIW, I believe the openib progress threads were written the they way
they were (i.e., without any opal progress thread support) because, at
least in the current setup, to get the opal progress thread support,
you have to turn on all the heavyweight locks, etc. These two
progress threads now simply pthread_create() and do minimal locking
between the main thread and themselves, without affecting the rest of
the locking machinery in the code base.

I'm not saying that's perfect (or even good); I'm just saying that
that's the way it currently is. Indeed, at a minimum, Pasha and I
have long talked about merging these two progress threads into 1. It
would be even better if we could merge these two project threads into
some other infrastructure. But it's always been somewhat of a low
priority; we've never gotten a round tuit...

Jeff Squyres
For corporate legal information go to: