Re: [OMPI devel] RFC: Remove heterogeneous support

[Ralph Castain]

So it sounds like we may have a test platform, which leaves the question of 
repair

George: can you give us some idea of what was broken and/or pointers on what 
needs to be done to repair it?


On Apr 25, 2014, at 4:34 AM, Adrian Reber  wrote:

> On Fri, Apr 25, 2014 at 10:29:36AM +, Jeff Squyres (jsquyres) wrote:
>> On Apr 25, 2014, at 6:13 AM, Gilles Gouaillardet 
>>  wrote:
>> 
>>> it is possible to use qemu in order to emulate unavailable hardware.
>>> for what it's worth, i am now running a ppc64 qemu emulated virtual
>>> machine on an x86_64 workstation.
>>> this is pretty slow (2 hours for configure and even more for make) but
>>> enough to make simple tests/debugging.
>> 
>> 
>> Fair point.  I have a (very) dim recollection of someone raising the same 
>> point the last time we talked about heterogeneity.
>> 
>> If someone would volunteer to do this, and run MTT in this setup on a 
>> regular, preferably automated, schedule (something even as low as once a 
>> week would probably be fine), that would probably change the equation.
> 
> I have access to ppc64 machines (PPC970MP and PowerXCell) on which I
> could set up MTT.
> 
>   Adrian
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/04/14614.php

Re: [OMPI devel] RFC: Well-known mca parameters

[Ralph Castain]

So long as this isn't a requirement, I don't see an issue with standardizing 
the syntax. I suspect Jeff's concern is with hard-coding ompi_info (and all its 
flavors) with an option that looks for a specific MCA param from every 
component. Seems somewhat icky from a software design standpoint, and 
inflexible.

Perhaps creating a special MCA param "class" might make that more palatable? So 
we aren't looking for a particular string inside an MCA param name when someone 
gives that ompi_info option, but instead printing all params of a specific type?


On Apr 25, 2014, at 4:18 AM, Stephen Poole  wrote:

> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Although the one Mike suggests would be much easier for "end users", I
> think that in this
> case, if the end user is more of a Linux newbie, they would have scripts
> written for them,
> that the admins use or will be handed to them. Either way would be a
> great addition for
> system/build/runtime verification of the installed libraries.
> 
> Best
> Steve...
> 
> 
> On 4/25/14, 7:13 AM, Jeff Squyres (jsquyres) wrote:
>> On Apr 25, 2014, at 7:01 AM, Mike Dubman  wrote:
>> 
>> ompi_info --all --parsable | egrep ':(compile|run)time_version'
>>> 
>>> yep, this is much better, but I don`t think we should count on
> end-user to be unix regex guru.
>> 
>> I thought you said this was for support scripts?
>> 
>> Users can easily do this:
>> 
>>  ompi_info --all --parsable | grep time_version
>> 
>> Or even
>> 
>>  ompi_info --all --parsable | grep _version
>> 
>> Or even
>> 
>>  ompi_info --all --parsable | grep version
>> 
>> 
>>> Ideally, following would be much user-friendlier:
>>> 
>>> ompi_info --all --parsable --print-sys-libs-versions
>>> 
>>> 
>>> 
>>> 
>>> On Fri, Apr 25, 2014 at 1:32 PM, Jeff Squyres (jsquyres)
>  wrote:
>>> On Apr 24, 2014, at 1:38 AM, Mike Dubman 
> wrote:
>>> 
 ** prefix each well-known MCA param with "print_":
>>> 
>>> I like the overall idea of this RFC, but I'm not wild about this
> specific word "print" -- it seems weird.  All the MCA parameters are
> *printed* -- the word "print" doesn't really distinguish anything here.
>>> 
>>> (I know I'm just harping on a word, but I think it's an important
> word here... :-) )
>>> 
>>> Got a better suggestion, perchance?  (I don't, offhand...)
>>> 
 ** Define two well-known mca parameters indicating external library
> runtime and compiletime versions, i.e.:
 
 print_compiletime_version
 print_runtime_version
 
 The following command will show all exposed well-known mca params
> from all components:
 ompi_info --parsable -l 9 |grep ":print_"
>>> 
>>> How about changing this a bit (hoping my regexp syntax is correct at
> 6:30am before coffee...):
>>> 
>>> ompi_info --all --parsable | egrep ':(compile|run)time_version'
>>> 
>>> Then the "print_" prefix isn't needed.
>>> 
>>> --
>>> Jeff Squyres
>>> jsquy...@cisco.com
>>> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>>> 
>>> ___
>>> devel mailing list
>>> de...@open-mpi.org
>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/04/14610.php
>>> 
>>> ___
>>> devel mailing list
>>> de...@open-mpi.org
>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/04/14611.php
>> 
>> 
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJTWkSZAAoJECiO+w6Set8uDWgP/2Lnx2j1foBu85sRtHwIqU72
> AdQGPvCqbiXZ3Sn32ODJgCE6lGm38W075HqETN3CFfrawvLLpAjsnLs2mdA1GcZq
> buoPVuFAHQQZ4FM7y+TGUt0NyMAsMDWfBR8t9JdyMZdP7fHYhGitkuGshItivWmQ
> 0j3KYzKFRe9qVGNvAc+f6eG7DnC+vUFNMZZ6APg62mYB7v//4NGhhrvHpYgD5jG2
> S3kA1QfvM7xPy6rOL4gvyA6LRnFsNnQmKKLEJFXhPazwy5/5Aop8iwc2TxqVBsZE
> Jw4B6ZrTKrQCzfuN4vN6jgeYHwhlZHKZqtVDMoIWHKwhJMvXlH8aTmeDqqj6sAfl
> wknbew6BETuuIkszyRr0BjZrf4zjJ18vqDoRwFNa8p6Wc3cbhK96kl6fXquxTd4z
> GIuRAIVqemEUGNKnGyuItYuVimkkvts5Ve5c/BxpMBT3oQX1LzOxb6+mcwzdR0dD
> HK82VQlycFegLQ9+ERLgYEkcfmyZlvB+x/pwtx9RRMOd177w5fCo8hTTnkmWJNq2
> jfq5cDiAW7knBJ1ZOGvMjp8RDpBMyMHjr6WCxQC3y+szR0TcMWrFUddcM2/2OBxF
> YfFCP5jaeCQOOmDh1kcntcFoLw43io2xHFr/UwmfXeDhh/IFQrnEmshjvl/ZFF8n
> RZogS6K9ty1C9x5GCBm4
> =O0Fa
> -END PGP SIGNATURE-
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/04/14613.php

Re: [OMPI devel] RFC: Well-known mca parameters

[Ralph Castain]

On Apr 24, 2014, at 9:41 PM, Mike Dubman  wrote:

> not a requirement of course, but warm recommendation. Like you mentioned:
> "component developers who choose to expose such information do so using the 
> suggested syntax, then that is a different proposal."
> 
> >>>FWIW: we do not (and cannot, for licensing reasons) link against Slurm, so 
> >>>please don't include it in such lists to avoid giving anyone even a 
> >>>passing thought that we do so.
> 
> I don`t understand, today we have "--with-slurm --with-pmi" for dynamic link 
> with slurm and others where we call slurm functions from OMPI code. how 
> calling slurm.getVersion() is different?

We do *not* dynamically link with libslurm, Mike. All --with-slurm does is tell 
us to build the Slurm-related RAS and PLM components. Those components do *not* 
link against libslurm - they (a) read the environment for slurm envars to get 
the allocation and (b) fork/exec srun commands to launch our daemons. Under no 
conditions do we ever call a slurm function.

The PMI functions are specifically licensed differently to allow apps to use 
them without this unfortunate side effect.

> 
> afaik, dynamic linking (as we do it today) does not violate current licensing 
> model.

This is *not* true. If you include a slurm header, which you must do in order 
to call a slurm function, then the GPL license pulls all of OMPI into GPL. 

> 
> 
> 
> On Fri, Apr 25, 2014 at 5:39 AM, Ralph Castain  wrote:
> Just for clarification: are you proposing that we *require* every component 
> that links against an external library to include these parameters? If so, 
> that seems a significant requirement as quite a few of our components do so.
> 
> On the other hand, if you are proposing that those component developers who 
> choose to expose such information do so using the suggested syntax, then that 
> is a different proposal.
> 
> Just want to understand what you are proposing - a requirement on components, 
> or a syntax for those who choose to support this capability?
> 
> FWIW: we do not (and cannot, for licensing reasons) link against Slurm, so 
> please don't include it in such lists to avoid giving anyone even a passing 
> thought that we do so.
> 
> 
> 
> On Apr 23, 2014, at 10:38 PM, Mike Dubman  wrote:
> 
>> 
>> WHAT:
>> * Formalize well-known MCA parameters that can be used by any component to 
>> represent external dependencies for this component. 
>> 
>> * Component can set that well-known MCA r/o parameters to expose to the 
>> end-users different setup related traits of the OMPI installation.
>> 
>> Example:
>> 
>> ompi_info can print for every component which depends on external library:
>> - ext lib runtime version used by component
>> - ext lib compiletime version used by component
>> 
>> slurm: v2.6.6
>> mtl/mxm: v2.5
>> btl/verbs: v3.2
>> btl/usnic: v1.1
>> coll/fca: v2.5
>> ...
>> 
>> End-user or site admin or OMPI vendor can aggregate this information by some 
>> script and generate report if given installation compiles with site/vendor 
>> rules.
>> 
>> * The "well-known" mca parameters can be easily extracted from ALL 
>> components by grep-like utilities.
>> 
>> * Current proposal:
>> 
>> ** prefix each well-known MCA param with "print_":
>> ** Define two well-known mca parameters indicating external library runtime 
>> and compiletime versions, i.e.:
>>  
>> print_compiletime_version
>> print_runtime_version
>> 
>> The following command will show all exposed well-known mca params from all 
>> components:
>> ompi_info --parsable -l 9 |grep ":print_"
>> 
>> 
>> WHY:
>> 
>> * Better support-ability: site/vendor can provide script which will check if 
>> OMPI installation complies to release notes or support matrix.
>> 
>> 
>> WHEN:
>> 
>> - Next teleconf
>> - code can be observed here: https://svn.open-mpi.org/trac/ompi/ticket/4556
>>   
>> 
>> Comments?
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/devel/2014/04/14590.php
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/04/14601.php
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/04/14604.php

Re: [OMPI devel] mosix patches

[Pavel V. Kaygorodov]

Hi!

> I'm the original developer. The patch never got merged, but I have patches to 
> some branches. Which version are you using?

For now, I'm not sticking to any specific version, I have spent last 3 days 
trying to adapt patches from mosix.org to 1.6.X, but without significant 
success :)
Which version are you recommend?


Pavel.

P.S. I have found ompi-mosix project on 
https://bitbucket.org/jsquyres/ompi-mosix/src , but it does not compiling too :(




> What is current status of mosix support in OpenMPI?
> I have tried patches from 
> http://www.cs.huji.ac.il/wikis/MediaWiki/mosix/index.php/Process_migration_for_OpenMPI
>  but without any success, even on 1.6 branch.
> 
> With best regards,
>   Pavel.

Re: [OMPI devel] RFC: Remove heterogeneous support

[Adrian Reber]

On Fri, Apr 25, 2014 at 10:29:36AM +, Jeff Squyres (jsquyres) wrote:
> On Apr 25, 2014, at 6:13 AM, Gilles Gouaillardet 
>  wrote:
> 
> > it is possible to use qemu in order to emulate unavailable hardware.
> > for what it's worth, i am now running a ppc64 qemu emulated virtual
> > machine on an x86_64 workstation.
> > this is pretty slow (2 hours for configure and even more for make) but
> > enough to make simple tests/debugging.
> 
> 
> Fair point.  I have a (very) dim recollection of someone raising the same 
> point the last time we talked about heterogeneity.
> 
> If someone would volunteer to do this, and run MTT in this setup on a 
> regular, preferably automated, schedule (something even as low as once a week 
> would probably be fine), that would probably change the equation.

I have access to ppc64 machines (PPC970MP and PowerXCell) on which I
could set up MTT.

Adrian

Re: [OMPI devel] RFC: Well-known mca parameters

[Stephen Poole]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Although the one Mike suggests would be much easier for "end users", I
think that in this
case, if the end user is more of a Linux newbie, they would have scripts
written for them,
that the admins use or will be handed to them. Either way would be a
great addition for
system/build/runtime verification of the installed libraries.

Best
Steve...


On 4/25/14, 7:13 AM, Jeff Squyres (jsquyres) wrote:
> On Apr 25, 2014, at 7:01 AM, Mike Dubman  wrote:
>
> ompi_info --all --parsable | egrep ':(compile|run)time_version'
>>
>> yep, this is much better, but I don`t think we should count on
end-user to be unix regex guru.
>
> I thought you said this was for support scripts?
>
> Users can easily do this:
>
>   ompi_info --all --parsable | grep time_version
>
> Or even
>
>   ompi_info --all --parsable | grep _version
>
> Or even
>
>   ompi_info --all --parsable | grep version
>
>
>> Ideally, following would be much user-friendlier:
>>
>> ompi_info --all --parsable --print-sys-libs-versions
>>
>>
>>
>>
>> On Fri, Apr 25, 2014 at 1:32 PM, Jeff Squyres (jsquyres)
 wrote:
>> On Apr 24, 2014, at 1:38 AM, Mike Dubman 
wrote:
>>
>>> ** prefix each well-known MCA param with "print_":
>>
>> I like the overall idea of this RFC, but I'm not wild about this
specific word "print" -- it seems weird.  All the MCA parameters are
*printed* -- the word "print" doesn't really distinguish anything here.
>>
>> (I know I'm just harping on a word, but I think it's an important
word here... :-) )
>>
>> Got a better suggestion, perchance?  (I don't, offhand...)
>>
>>> ** Define two well-known mca parameters indicating external library
runtime and compiletime versions, i.e.:
>>>
>>> print_compiletime_version
>>> print_runtime_version
>>>
>>> The following command will show all exposed well-known mca params
from all components:
>>> ompi_info --parsable -l 9 |grep ":print_"
>>
>> How about changing this a bit (hoping my regexp syntax is correct at
6:30am before coffee...):
>>
>> ompi_info --all --parsable | egrep ':(compile|run)time_version'
>>
>> Then the "print_" prefix isn't needed.
>>
>> --
>> Jeff Squyres
>> jsquy...@cisco.com
>> For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
>>
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post:
http://www.open-mpi.org/community/lists/devel/2014/04/14610.php
>>
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post:
http://www.open-mpi.org/community/lists/devel/2014/04/14611.php
>
>

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTWkSZAAoJECiO+w6Set8uDWgP/2Lnx2j1foBu85sRtHwIqU72
AdQGPvCqbiXZ3Sn32ODJgCE6lGm38W075HqETN3CFfrawvLLpAjsnLs2mdA1GcZq
buoPVuFAHQQZ4FM7y+TGUt0NyMAsMDWfBR8t9JdyMZdP7fHYhGitkuGshItivWmQ
0j3KYzKFRe9qVGNvAc+f6eG7DnC+vUFNMZZ6APg62mYB7v//4NGhhrvHpYgD5jG2
S3kA1QfvM7xPy6rOL4gvyA6LRnFsNnQmKKLEJFXhPazwy5/5Aop8iwc2TxqVBsZE
Jw4B6ZrTKrQCzfuN4vN6jgeYHwhlZHKZqtVDMoIWHKwhJMvXlH8aTmeDqqj6sAfl
wknbew6BETuuIkszyRr0BjZrf4zjJ18vqDoRwFNa8p6Wc3cbhK96kl6fXquxTd4z
GIuRAIVqemEUGNKnGyuItYuVimkkvts5Ve5c/BxpMBT3oQX1LzOxb6+mcwzdR0dD
HK82VQlycFegLQ9+ERLgYEkcfmyZlvB+x/pwtx9RRMOd177w5fCo8hTTnkmWJNq2
jfq5cDiAW7knBJ1ZOGvMjp8RDpBMyMHjr6WCxQC3y+szR0TcMWrFUddcM2/2OBxF
YfFCP5jaeCQOOmDh1kcntcFoLw43io2xHFr/UwmfXeDhh/IFQrnEmshjvl/ZFF8n
RZogS6K9ty1C9x5GCBm4
=O0Fa
-END PGP SIGNATURE-

Re: [OMPI devel] RFC: Well-known mca parameters

[Jeff Squyres (jsquyres)]

On Apr 25, 2014, at 7:01 AM, Mike Dubman  wrote:

> >>>ompi_info --all --parsable | egrep ':(compile|run)time_version'
> 
> yep, this is much better, but I don`t think we should count on end-user to be 
> unix regex guru.

I thought you said this was for support scripts?

Users can easily do this:

  ompi_info --all --parsable | grep time_version

Or even

  ompi_info --all --parsable | grep _version

Or even

  ompi_info --all --parsable | grep version


> Ideally, following would be much user-friendlier:
> 
> ompi_info --all --parsable --print-sys-libs-versions
> 
> 
> 
> 
> On Fri, Apr 25, 2014 at 1:32 PM, Jeff Squyres (jsquyres)  
> wrote:
> On Apr 24, 2014, at 1:38 AM, Mike Dubman  wrote:
> 
> > ** prefix each well-known MCA param with "print_":
> 
> I like the overall idea of this RFC, but I'm not wild about this specific 
> word "print" -- it seems weird.  All the MCA parameters are *printed* -- the 
> word "print" doesn't really distinguish anything here.
> 
> (I know I'm just harping on a word, but I think it's an important word 
> here... :-) )
> 
> Got a better suggestion, perchance?  (I don't, offhand...)
> 
> > ** Define two well-known mca parameters indicating external library runtime 
> > and compiletime versions, i.e.:
> >
> > print_compiletime_version
> > print_runtime_version
> >
> > The following command will show all exposed well-known mca params from all 
> > components:
> > ompi_info --parsable -l 9 |grep ":print_"
> 
> How about changing this a bit (hoping my regexp syntax is correct at 6:30am 
> before coffee...):
> 
> ompi_info --all --parsable | egrep ':(compile|run)time_version'
> 
> Then the "print_" prefix isn't needed.
> 
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/04/14610.php
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/04/14611.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] RFC: Well-known mca parameters

[Mike Dubman]

>>>ompi_info --all --parsable | egrep ':(compile|run)time_version'

yep, this is much better, but I don`t think we should count on end-user to
be unix regex guru.
Ideally, following would be much user-friendlier:

ompi_info --all --parsable --print-sys-libs-versions




On Fri, Apr 25, 2014 at 1:32 PM, Jeff Squyres (jsquyres)  wrote:

> On Apr 24, 2014, at 1:38 AM, Mike Dubman  wrote:
>
> > ** prefix each well-known MCA param with "print_":
>
> I like the overall idea of this RFC, but I'm not wild about this specific
> word "print" -- it seems weird.  All the MCA parameters are *printed* --
> the word "print" doesn't really distinguish anything here.
>
> (I know I'm just harping on a word, but I think it's an important word
> here... :-) )
>
> Got a better suggestion, perchance?  (I don't, offhand...)
>
> > ** Define two well-known mca parameters indicating external library
> runtime and compiletime versions, i.e.:
> >
> > print_compiletime_version
> > print_runtime_version
> >
> > The following command will show all exposed well-known mca params from
> all components:
> > ompi_info --parsable -l 9 |grep ":print_"
>
> How about changing this a bit (hoping my regexp syntax is correct at
> 6:30am before coffee...):
>
> ompi_info --all --parsable | egrep ':(compile|run)time_version'
>
> Then the "print_" prefix isn't needed.
>
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/04/14610.php
>

Re: [OMPI devel] RFC: Well-known mca parameters

[Jeff Squyres (jsquyres)]

On Apr 24, 2014, at 1:38 AM, Mike Dubman  wrote:

> ** prefix each well-known MCA param with "print_":

I like the overall idea of this RFC, but I'm not wild about this specific word 
"print" -- it seems weird.  All the MCA parameters are *printed* -- the word 
"print" doesn't really distinguish anything here.

(I know I'm just harping on a word, but I think it's an important word here... 
:-) )

Got a better suggestion, perchance?  (I don't, offhand...)

> ** Define two well-known mca parameters indicating external library runtime 
> and compiletime versions, i.e.:
>  
> print_compiletime_version
> print_runtime_version
> 
> The following command will show all exposed well-known mca params from all 
> components:
> ompi_info --parsable -l 9 |grep ":print_"

How about changing this a bit (hoping my regexp syntax is correct at 6:30am 
before coffee...):

ompi_info --all --parsable | egrep ':(compile|run)time_version'

Then the "print_" prefix isn't needed.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] RFC: Remove heterogeneous support

[Jeff Squyres (jsquyres)]

On Apr 25, 2014, at 6:13 AM, Gilles Gouaillardet 
 wrote:

> it is possible to use qemu in order to emulate unavailable hardware.
> for what it's worth, i am now running a ppc64 qemu emulated virtual
> machine on an x86_64 workstation.
> this is pretty slow (2 hours for configure and even more for make) but
> enough to make simple tests/debugging.


Fair point.  I have a (very) dim recollection of someone raising the same point 
the last time we talked about heterogeneity.

If someone would volunteer to do this, and run MTT in this setup on a regular, 
preferably automated, schedule (something even as low as once a week would 
probably be fine), that would probably change the equation.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] mosix patches

[Alex Margolin]

I'm the original developer. The patch never got merged, but I have patches
to some branches. Which version are you using?
On 24 Apr 2014 19:07, "Pavel V. Kaygorodov"  wrote:

> Hi!
>
> What is current status of mosix support in OpenMPI?
> I have tried patches from
> http://www.cs.huji.ac.il/wikis/MediaWiki/mosix/index.php/Process_migration_for_OpenMPIbut
>  without any success, even on 1.6 branch.
>
> With best regards,
>   Pavel.
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/04/14593.php
>

Re: [OMPI devel] RFC: Well-known mca parameters

[Mike Dubman]

Also, the reason for rfc is this:

https://svn.open-mpi.org/trac/ompi/ticket/4556#comment:5



On Fri, Apr 25, 2014 at 7:41 AM, Mike Dubman wrote:

> not a requirement of course, but warm recommendation. Like you mentioned:
> "component developers who choose to expose such information do so using
> the suggested syntax, then that is a different proposal."
>
> >>>FWIW: we do not (and cannot, for licensing reasons) link against Slurm,
> so please don't include it in such lists to avoid giving anyone even a
> passing thought that we do so.
>
> I don`t understand, today we have "--with-slurm --with-pmi" for dynamic
> link with slurm and others where we call slurm functions from OMPI code.
> how calling slurm.getVersion() is different?
>
> afaik, dynamic linking (as we do it today) does not violate current
> licensing model.
>
>
>
> On Fri, Apr 25, 2014 at 5:39 AM, Ralph Castain  wrote:
>
>> Just for clarification: are you proposing that we *require* every
>> component that links against an external library to include these
>> parameters? If so, that seems a significant requirement as quite a few of
>> our components do so.
>>
>> On the other hand, if you are proposing that those component developers
>> who choose to expose such information do so using the suggested syntax,
>> then that is a different proposal.
>>
>> Just want to understand what you are proposing - a requirement on
>> components, or a syntax for those who choose to support this capability?
>>
>> FWIW: we do not (and cannot, for licensing reasons) link against Slurm,
>> so please don't include it in such lists to avoid giving anyone even a
>> passing thought that we do so.
>>
>>
>>
>> On Apr 23, 2014, at 10:38 PM, Mike Dubman 
>> wrote:
>>
>>
>> WHAT:
>> * Formalize well-known MCA parameters that can be used by any component
>> to represent external dependencies for this component.
>>
>> * Component can set that well-known MCA r/o parameters to expose to the
>> end-users different setup related traits of the OMPI installation.
>>
>> Example:
>>
>> ompi_info can print for every component which depends on external library:
>> - ext lib runtime version used by component
>> - ext lib compiletime version used by component
>>
>> slurm: v2.6.6
>> mtl/mxm: v2.5
>> btl/verbs: v3.2
>> btl/usnic: v1.1
>> coll/fca: v2.5
>> ...
>>
>> End-user or site admin or OMPI vendor can aggregate this information by
>> some script and generate report if given installation compiles with
>> site/vendor rules.
>>
>> * The "well-known" mca parameters can be easily extracted from ALL
>> components by grep-like utilities.
>>
>> * Current proposal:
>>
>> ** prefix each well-known MCA param with "print_":
>> ** Define two well-known mca parameters indicating external library
>> runtime and compiletime versions, i.e.:
>>
>> print_compiletime_version
>> print_runtime_version
>>
>> The following command will show all exposed well-known mca params from
>> all components:
>> ompi_info --parsable -l 9 |grep ":print_"
>>
>>
>> WHY:
>>
>> * Better support-ability: site/vendor can provide script which will check
>> if OMPI installation complies to release notes or support matrix.
>>
>>
>> WHEN:
>>
>> - Next teleconf
>> - code can be observed here:
>> https://svn.open-mpi.org/trac/ompi/ticket/4556
>>
>>
>> Comments?
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post:
>> http://www.open-mpi.org/community/lists/devel/2014/04/14590.php
>>
>>
>>
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post:
>> http://www.open-mpi.org/community/lists/devel/2014/04/14601.php
>>
>
>

Re: [OMPI devel] RFC: Well-known mca parameters

[Mike Dubman]

not a requirement of course, but warm recommendation. Like you mentioned:
"component developers who choose to expose such information do so using the
suggested syntax, then that is a different proposal."

>>>FWIW: we do not (and cannot, for licensing reasons) link against Slurm,
so please don't include it in such lists to avoid giving anyone even a
passing thought that we do so.

I don`t understand, today we have "--with-slurm --with-pmi" for dynamic
link with slurm and others where we call slurm functions from OMPI code.
how calling slurm.getVersion() is different?

afaik, dynamic linking (as we do it today) does not violate current
licensing model.



On Fri, Apr 25, 2014 at 5:39 AM, Ralph Castain  wrote:

> Just for clarification: are you proposing that we *require* every
> component that links against an external library to include these
> parameters? If so, that seems a significant requirement as quite a few of
> our components do so.
>
> On the other hand, if you are proposing that those component developers
> who choose to expose such information do so using the suggested syntax,
> then that is a different proposal.
>
> Just want to understand what you are proposing - a requirement on
> components, or a syntax for those who choose to support this capability?
>
> FWIW: we do not (and cannot, for licensing reasons) link against Slurm, so
> please don't include it in such lists to avoid giving anyone even a passing
> thought that we do so.
>
>
>
> On Apr 23, 2014, at 10:38 PM, Mike Dubman 
> wrote:
>
>
> WHAT:
> * Formalize well-known MCA parameters that can be used by any component to
> represent external dependencies for this component.
>
> * Component can set that well-known MCA r/o parameters to expose to the
> end-users different setup related traits of the OMPI installation.
>
> Example:
>
> ompi_info can print for every component which depends on external library:
> - ext lib runtime version used by component
> - ext lib compiletime version used by component
>
> slurm: v2.6.6
> mtl/mxm: v2.5
> btl/verbs: v3.2
> btl/usnic: v1.1
> coll/fca: v2.5
> ...
>
> End-user or site admin or OMPI vendor can aggregate this information by
> some script and generate report if given installation compiles with
> site/vendor rules.
>
> * The "well-known" mca parameters can be easily extracted from ALL
> components by grep-like utilities.
>
> * Current proposal:
>
> ** prefix each well-known MCA param with "print_":
> ** Define two well-known mca parameters indicating external library
> runtime and compiletime versions, i.e.:
>
> print_compiletime_version
> print_runtime_version
>
> The following command will show all exposed well-known mca params from all
> components:
> ompi_info --parsable -l 9 |grep ":print_"
>
>
> WHY:
>
> * Better support-ability: site/vendor can provide script which will check
> if OMPI installation complies to release notes or support matrix.
>
>
> WHEN:
>
> - Next teleconf
> - code can be observed here:
> https://svn.open-mpi.org/trac/ompi/ticket/4556
>
>
> Comments?
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/04/14590.php
>
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/04/14601.php
>