Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] Using external libevent
From: Ralph Castain (rhc_at_[hidden])
Date: 2013-04-17 17:40:31


On Apr 17, 2013, at 1:19 PM, Orion Poplawski <orion_at_[hidden]> wrote:

> On 04/17/2013 01:40 PM, Ralph Castain wrote:
>>
>> On Apr 17, 2013, at 12:26 PM, Orion Poplawski <orion_at_[hidden]> wrote:
>>
>>> On 04/17/2013 12:38 PM, Paul Hargrove wrote:
>>>>
>>>> On Wed, Apr 17, 2013 at 10:40 AM, Orion Poplawski <orion_at_[hidden]
>>>> <mailto:orion_at_[hidden]>> 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 orion_at_[hidden]
> Boulder, CO 80301 http://www.nwra.com
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel