On Apr 17, 2013, at 1:19 PM, Orion Poplawski <or...@cora.nwra.com> wrote:
> On 04/17/2013 01:40 PM, Ralph Castain wrote: >> >> On Apr 17, 2013, at 12:26 PM, Orion Poplawski <or...@cora.nwra.com> wrote: >> >>> On 04/17/2013 12:38 PM, Paul Hargrove wrote: >>>> >>>> On Wed, Apr 17, 2013 at 10:40 AM, Orion Poplawski <or...@cora.nwra.com >>>> <mailto:or...@cora.nwra.com>> wrote: >>>> >>>> So, would you be willing to provide more of the rationale as to why >>>> libevent is bundled? >>>> >>>> >>>> >>>> Orion, >>>> >>>> I am NOT an Open MPI developer myself. So please don't take my response as >>>> speaking for the community. >>>> >>>> I found the following file useful in understanding WHY libevent is >>>> currently >>>> bundled in Open MPI: >>>> https://svn.open-mpi.org/source/xref/ompi-trunk/opal/mca/event/base/README.openmpi >>>> >>>> -Paul >>>> >>> >>> Thanks, that was helpful. From what I read there, it does not appear that >>> libevent is not being modified in a meaningful way as it would apply to >>> Fedora. In Fedora, all applications would be built against the same >>> libevent, so that should not be an issue. >> >> It depends upon how libevent was configured. For example, if Fedora >> configures libevent with thread support enabled, then the MPI job will see >> an unnecessary performance impact. Our users notice such things. At the very >> least, we'd have to detect how libevent was configured so we could (a) abort >> if it isn't the right minimum version, and (b) adjust behavior to reflect >> the configuration and capabilities of the libevent version being used. >> >> Complicated, and probably not what users would expect. > > Okay, that sounds like that might be a compelling reason. The Fedora version > is indeed compiled with thread support (i.e. without > --disable-thread-support). Yeah, I would expect that to be the case > >>> And assuming that the Fedora libevent properly detects kqueue and epoll >>> (if applicable) that should be okay. >> >> I would suggest checking that assumption before committing to it. > > http://kojipkgs.fedoraproject.org//packages/libevent/2.0.18/3.fc19/data/logs/x86_64/build.log > > checking for epoll_ctl... yes > > checking for TAILQ_FOREACH in sys/queue.h... yes > (not sure if this is "kqueue" - I don't see that string anywhere). I'll dig a little more - I believe the issue is that our tests are a little stricter than the ones packaged in libevent to ensure that IO forwarding will work as required, but I don't know if they absorbed ours or not. Will check. > >>> >>> So other than openmpi expecting to work with a specific version of >>> libevent, I'm not seeing compelling reason why bundling is necessary (at >>> least for Fedora packaging). If there is, please let me know. >> >> I'd hate to make a Fedora-specific change and then have users complain >> because of things like performance degradation on that platform. As Jeff >> pointed out, this is how we've distributed OMPI on every platform since day >> one - I'm not hearing a compelling reason to change that policy. We'd have >> to discuss any such request at our next weekly meeting (Tues mornings). > > Of course. You've raised a good question - I'll bring it up at the next meeting and see what people think. Thanks! Ralph > > > -- > Orion Poplawski > Technical Manager 303-415-9701 x222 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane or...@nwra.com > Boulder, CO 80301 http://www.nwra.com > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
