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
>> - 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.
> I'm speaking solely of the RTE impact and issues here, of course -
> Josh would have to address the MPI perspective.
>> 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
>> Can you provide an example of where something isn't building? I can't
>> find it on any platform available to me.
>> On Aug 20, 2009, at 4:32 PM, George Bosilca wrote:
>>> 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.
>>> devel mailing list
>> devel mailing list
>> devel mailing list
> devel mailing list