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
$0.02...
> 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
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
