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. > > Fair enough - but could you put a comment to this effect into the patch? Comment added. > But I'm still not too happy about even the very unlikely risk of > something executing "random stuff" depending on kernel version. > For now, could you update the comments to that effect that: > > "These kernel functions are available on kernel versions 2.6.15 and > greater" + ", and running this software on earlier versions will result > in undefined behaviour." Comment added. > What I'm suggesting is not to parse information out of the build host, > but rather using the configured toolchain and options and try to > assemble the 64-bit atomic instructions. This would make it easy to > rebuild a generic ARMv6 package to support 64-bit atomics by just adding > -march=armv6zk to CFLAGS. Ah, I get it. I may see if I can come up with a nice test in the near future. For now, revised patch attached. ompi_armv5-3rd.diff Description: Binary data
Re: [OMPI devel] [PATCH] Open MPI on ARMv5
Thanks, I'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; Jeffrey Squyres > 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. > > > > Fair enough - but could you put a comment to this effect into the > patch? > Comment added. > > > But I'm still not too happy about even the very unlikely risk of > > something executing "random stuff" depending on kernel version. > > For now, could you update the comments to that effect that: > > > > "These kernel functions are available on kernel versions 2.6.15 and > > greater" + ", and running this software on earlier versions will > result > > in undefined behaviour." > Comment added. > > > What I'm suggesting is not to parse information out of the build > host, > > but rather using the configured toolchain and options and try to > > assemble the 64-bit atomic instructions. This would make it easy to > > rebuild a generic ARMv6 package to support 64-bit atomics by just > adding > > -march=armv6zk to CFLAGS. > Ah, I get it. I may see if I can come up with a nice test in the near > future. > > For now, revised patch attached. -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Re: [OMPI devel] [PATCH] Open MPI on ARMv5
I'm good with it as long as you guys are. Re the "...for now" comment; does this imply that you're going to do more later? BTW, I assume this is for trunk and the v1.6 branch, right? On Apr 30, 2012, at 9:47 AM, Leif Lindholm wrote: > Thanks, > > I'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; Jeffrey Squyres >> 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. >>> >>> Fair enough - but could you put a comment to this effect into the >> patch? >> Comment added. >> >>> But I'm still not too happy about even the very unlikely risk of >>> something executing "random stuff" depending on kernel version. >>> For now, could you update the comments to that effect that: >>> >>> "These kernel functions are available on kernel versions 2.6.15 and >>> greater" + ", and running this software on earlier versions will >> result >>> in undefined behaviour." >> Comment added. >> >>> What I'm suggesting is not to parse information out of the build >> host, >>> but rather using the configured toolchain and options and try to >>> assemble the 64-bit atomic instructions. This would make it easy to >>> rebuild a generic ARMv6 package to support 64-bit atomics by just >> adding >>> -march=armv6zk to CFLAGS. >> Ah, I get it. I may see if I can come up with a nice test in the near >> future. >> >> For now, revised patch attached. > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] libevent socket code
Can you send me a copy of the warnings, or tell me which machine at LANL is generating them? I'm working on libevent now (found a bug they are helping with) and can take a look at it. On Apr 25, 2012, at 11:05 AM, Nathan Hjelm wrote: > Let me take a look. The code in question is in evutil.c and > bufferevent_sock.c . If there is no option we might be able to get away with > just removing these files from the Makefile.am. > > -Nathan > > On Wed, 25 Apr 2012, Jeff Squyres wrote: > >> On Apr 25, 2012, at 12:50 PM, Ralph Castain wrote: >> >>> Can't it be done with configuring --without-libevent-sockets or some such >>> thing? I really hate munging the code directly as it creates lots of >>> support issues and makes it harder to upgrade. >> >> If there's a libevent configure option we should be using, we can probably >> set that to be enabled by default. Let me know. >> >> -- >> 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 >> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
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"). It does apply cleanly-ish (non-interactively) on top of 1.5.5, but I don't 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 as you guys are. Re the "...for now" comment; does this imply that you're going to do more later? BTW, I assume this is for trunk and the v1.6 branch, right? On Apr 30, 2012, at 9:47 AM, Leif Lindholm wrote: > Thanks, > > I'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; Jeffrey Squyres >> 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. >>> >>> Fair enough - but could you put a comment to this effect into the >> patch? >> Comment added. >> >>> But I'm still not too happy about even the very unlikely risk of >>> something executing "random stuff" depending on kernel version. >>> For now, could you update the comments to that effect that: >>> >>> "These kernel functions are available on kernel versions 2.6.15 and >>> greater" + ", and running this software on earlier versions will >> result >>> in undefined behaviour." >> Comment added. >> >>> What I'm suggesting is not to parse information out of the build >> host, >>> but rather using the configured toolchain and options and try to >>> assemble the 64-bit atomic instructions. This would make it easy to >>> rebuild a generic ARMv6 package to support 64-bit atomics by just >> adding >>> -march=armv6zk to CFLAGS. >> Ah, I get it. I may see if I can come up with a nice test in the near >> future. >> >> For now, revised patch attached. > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Re: [OMPI devel] [PATCH] Open MPI on ARMv5
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-interactively) on top of 1.5.5, but I don't > know if any further drops off 1.5 are planned? No, 1.5.5 was the end of that line. Let me explain our versioning: - 1.odd numbers (1.5.x) are "Feature" series. - 1.even numbers (1.6.x) are "Stable" series. 1.6 is just a re-naming from the 1.5 series (i.e., it's not a new branch from the trunk). It represents the maturity of a feature series. Once it transitions to 1.6/stable, no new features can be added/removed -- only bug fixes. See http://www.open-mpi.org/software/ompi/versions/ if you care for more info. So I committed the ARM patch against the trunk and filed a CMR for 1.6. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
