Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] New frameworks and contribs in the trunk
From: George Bosilca (bosilca_at_[hidden])
Date: 2009-08-24 17:17:34


On Aug 21, 2009, at 07:33 , Ralph Castain wrote:

> Hi Rich
>
> On Aug 21, 2009, at 5:14 AM, Graham, Richard L. wrote:
>
>> I have several questions here - since process migration is an open
>> research question,
>> and there is more than one way to address the issue -
>> - Is this being implemented as a component, so that other
>> approaches can be used ?
>
> Absolutely - we have several organizations involved, all with
> competing approaches

This become a recurrent statement, every time something smelly should
be defended.

>> - If so, what sort of component interface is being considered ?
>
> Still being determined. One reason for exposing the frameworks at
> this time is that much of the ongoing effort may occur in separate,
> hidden tmp branches for proprietary reasons. The eventual source
> code for those components may well never be committed, but the
> frameworks need to be in the system so that MCA will pickup the
> binary modules.

This is a wrong reason. We did multi-institution work in the past
starting from a tmp branch. The only overhead is that somebody has to
keep the copy in sync with the trunk, but this approach at least has
the merit to keep our trunk [more or less] clean.

> I deliberately left the frameworks "inactive" so that changes in the
> APIs can be done as the work progresses without impacting the OMPI
> community. The participants need to develop a little further before
> we fully understand what the APIs need to be - a little hard to
> openly discuss them without exposing potentially proprietary algos.
> The hope is that, as people develop their components, they can
> identify missing needs in the API so at least that much can be
> safely communicated and resolved.
>
>> - What is the impact (or expected impact) on the rest of the system ?
>
> For anyone who doesn't explicitly build it and turn it on, nothing.
> For those who do, there will be no impact on MPI procs themselves as
> they won't load nor activate these frameworks. There will be an
> increased orted footprint and activity level, which could
> potentially reduce performance by stealing cycles from MPI procs -
> obviously, that depends on #procs vs cores and other factors.

If nobody knows how to do it, this _clearly_ should be a good enough
reason to do the work in a temp branch before polluting the trunk.

   george.

>
>
> I'm speaking solely of the RTE impact and issues here, of course -
> Josh would have to address the MPI perspective.
>
> HTH
> Ralph
>
>>
>> Thanks,
>> Rich
>>
>>
>> On 8/20/09 6:57 PM, "Ralph Castain" <rhc_at_[hidden]> wrote:
>>
>> Hmmm...I'm afraid I cannot entirely substantiate your concerns.
>> Everything compiles just fine for me under both Linux and OSX. True,
>> the files are not completely instantiated on the trunk at this time,
>> but they also are not activated on the trunk for precisely that
>> reason.
>>
>> Can you provide an example of where something isn't building? I can't
>> find it on any platform available to me.
>>
>> Thanks
>> Ralph
>>
>> On Aug 20, 2009, at 4:32 PM, George Bosilca wrote:
>>
>>> Ralph,
>>>
>>> I'm a little bit concerned about the commits stated below as their
>>> quality doesn't match the usual quality standards of the trunk.
>>> There are several issues: mostly empty files, names coming from
>>> other frameworks, failure to compile on several platforms (including
>>> Linux and MAC OS X). I'm more than happy to see research code in the
>>> trunk, and I will be really interested to see the proof that
>>> preemptive migration works. However, the quality of the trunk should
>>> not suffer.
>>>
>>> Moreover, we have mercurial and svn temporary repositories for such
>>> kind of work. And we did force people in the past to work on
>>> temporary branches before such large commits on the trunk.
>>>
>>> Please reconsider your patches.
>>>
>>> Thanks,
>>> george.
>>>
>>>
>>>
>>> https://svn.open-mpi.org/trac/ompi/changeset/21849
>>> https://svn.open-mpi.org/trac/ompi/changeset/21850
>>> https://svn.open-mpi.org/trac/ompi/changeset/21848
>>> https://svn.open-mpi.org/trac/ompi/changeset/21847
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel_at_[hidden]
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel