Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI devel] System V Shared Memory for Open MPI:Request for Community Input and Testing
From: N.M. Maclaren (nmm1_at_[hidden])
Date: 2010-05-04 10:14:56

On May 4 2010, Terry Dontje wrote:
>Ralph Castain wrote:
>>> Is a configure-time test good enough? For example, are all Linuxes
>>> the same in this regard. That is if you built OMPI on RH and it
>>> configured in the new SysV SM will those bits actually run on other
>>> Linux systems correctly? I think Jeff had hinted to this similarly
>>> when suggesting this may need to be a runtime test.
>> I don't think we have ever enforced that requirement, nor am I sure
>> the current code would meet it. We have a number of components that
>> test for ability to build, but don't check again at run-time.
>> Generally, the project has followed the philosophy of "build on the
>> system you intend to run on".
>There is at least one binary distribution that does build on one linux
>and allows to be installed on several others. That is the reason I
>bring up the above. The community can make a stance that that one
>distribution does not matter for this case or needs to handle it on its
>own. In the grand scheme of things it might not matter but I wanted to
>at least stand up and be heard.

There is a gradation involved. Building on one distribution and using
on another is one thing. But the same distribution can use differently
built kernels, and the same system can be reconfigured (including both
package updating and parameter changing). It is highly undesirable to
use volatile parameters in non-volatile context.

A lot of applications need rebuilding when the administrator updates
packages or makes configuration changes; that's not good and should be
avoided if at all possible. Given the way that systems are currently
configured, and the design of the autoconfigure mechanism, it's probably
not wholly avoidable. But it's still a very nasty gotcha.

Nick Maclaren.