Correct.
> -Original Message-
> From: Jeff Squyres [mailto:jsquy...@cisco.com]
> Sent: 04 May 2012 14:49
> To: Leif Lindholm
> Cc: Evan Clinton; Peter Robinson; Open MPI Developers
> Subject: Re: [OMPI devel] [PATCH] Open MPI on ARMv5
>
> Ok. I'm parsing t
Ok. I'm parsing this to mean: v1.6 can proceed without further changes. There
may be further changes that may be desirable for 1.6.x, however.
Right?
On May 4, 2012, at 9:45 AM, Leif Lindholm wrote:
>>> It causes no problems on/for the systems supported by trunk before
>> the patch went in -
> > It causes no problems on/for the systems supported by trunk before
> the patch went in - it just means that in some situations it doesn't
> work on/for the systems enabled by that patch.
>
> I'm having trouble parsing that. :-)
Sorry :)
> Does this mean that we put in the patch, but it will
On May 4, 2012, at 7:16 AM, Leif Lindholm wrote:
> It causes no problems on/for the systems supported by trunk before the patch
> went in - it just means that in some situations it doesn't work on/for the
> systems enabled by that patch.
I'm having trouble parsing that. :-)
Does this mean tha
012 11:51
> To: Evan Clinton
> Cc: Peter Robinson; Leif Lindholm; Open MPI Developers
> Subject: Re: [OMPI devel] [PATCH] Open MPI on ARMv5
>
> What I need to know in the immediate future is: does this affect the
> new patch that we just put in the 1.6rc2 tarball?
>
> http://
What I need to know in the immediate future is: does this affect the new patch
that we just put in the 1.6rc2 tarball?
http://www.open-mpi.org/community/lists/devel/2012/05/10968.php
Meaning: I want to release 1.6 in the immediate future. Is this a blocker? If
so, how fast can we get a f
What I mean to say is that, as far as I can tell, in Open MPI's
configure stuff there's a switch based on what it detects the host
processor as (and this detection could be overridden by specifying the
--host= thing); this is probably not the best way to do it.
(sorry for the double-post again, da
> The Fedora guys are having trouble building the armv5tel variant (well, they
> did before this patch too, but... :)
> http://arm.koji.fedoraproject.org/koji/getfile?taskID=790343&name=build.log
Ah, I think the problem is that the build system is not playing nicely
with cross-compiles (which it
Evan Clinton
> Subject: Re: [OMPI devel] [PATCH] Open MPI on ARMv5
>
> My only question mark was with regards to the lack of out-of-line
> assembly implementations for the older architecture versions (as in "I
> don't know whether people would care about that or not").
On Apr 30, 2012, at 2:04 PM, Leif Lindholm wrote:
> My only question mark was with regards to the lack of out-of-line assembly
> implementations for the older architecture versions (as in "I don't know
> whether people would care about that or not").
>
> It does apply cleanly-ish (non-interacti
know
if any further drops off 1.5 are planned?
/
Leif
From: Jeff Squyres [jsquy...@cisco.com]
Sent: 30 April 2012 21:19
To: Leif Lindholm
Cc: Evan Clinton; Open MPI Developers
Subject: Re: [OMPI devel] [PATCH] Open MPI on ARMv5
I'm good with it as long
7;m happy for this to go in - Jeff?
>
> /
>Leif
>
>> -Original Message-
>> From: nave.notn...@gmail.com [mailto:nave.notn...@gmail.com] On Behalf
>> Of Evan Clinton
>> Sent: 30 April 2012 05:12
>> To: Leif Lindholm
>> Cc: Open MPI Developers; Je
; Subject: Re: [OMPI devel] [PATCH] Open MPI on ARMv5
>
> Thanks again for the comments.
>
> >> Quote the documentation, __kuser_cmpxchg "already includes memory
> >> barriers as needed," so the code using it shouldn't need anything
> >> extra.
>
Thanks again for the comments.
>> Quote the documentation, __kuser_cmpxchg "already includes memory
>> barriers as needed," so the code using it shouldn't need anything
>> extra.
>
> Fair enough - but could you put a comment to this effect into the patch?
Comment added.
> But I'm still not too ha
On 04/25/12 01:50, Evan Clinton wrote:
- The v5 code doesn't actually make use of the kuser helper barriers
in its versions of opal_atomic_cmpset_acq/rel.
Quote the documentation, __kuser_cmpxchg "already includes memory
barriers as needed," so the code using it shouldn't need anything
extra.
Hi Leif, thanks for the comments.
> - The v5 code doesn't actually make use of the kuser helper barriers
> in its versions of opal_atomic_cmpset_acq/rel.
Quote the documentation, __kuser_cmpxchg "already includes memory
barriers as needed," so the code using it shouldn't need anything
extra.
> -
9 April 2012 16:21
> To: Open MPI Developers; Leif Lindholm
> Subject: Re: [OMPI devel] [PATCH] Open MPI on ARMv5
>
> Thanks Evan!
>
> (sorry for the delay in replying -- I was on vacation all last week and
> I'm *still* catching up...)
>
> Lief -- does this look good t
Thanks Evan!
(sorry for the delay in replying -- I was on vacation all last week and I'm
*still* catching up...)
Lief -- does this look good to you?
On Apr 13, 2012, at 11:13 PM, Evan Clinton wrote:
> At present Open MPI only supports ARMv7 processors. Attached is a
> patch against current t
At present Open MPI only supports ARMv7 processors. Attached is a
patch against current trunk (r26270) that extends the atomic
operations and memory barriers code to work with ARMv5 and ARMv6 ones,
too.
For v6, the only changes were to use "mcr p15, 0, r0, c7, c10, 5"
instead of the unavailable D
19 matches
Mail list logo
