Re: [OMPI devel] [EXTERNAL] SPARC V8+ question

Following up on the mailing list, Paul and I think this is gcc being silly; it didn't pass the right architecture flag to the assembler, which barfed at the Sparc V9 instruction (compare and swap). So the test worked as it should and we'll figure out the gcc thing as we go. I've filed a change

Re: [OMPI devel] [EXTERNAL] SPARC V8+ question

Paul - Can you send me the config.log from this failure? Thanks, Brian Sent with Good (www.good.com) -Original Message- From: Paul Hargrove [phhargr...@lbl.gov] Sent: Wednesday, January 29, 2014 04:11 PM Mountain Standard Time To: Open MPI Developers Subje

Re: [OMPI devel] [EXTERNAL] 1.7.4rc: linux/ppc32/xlc-11.1 build failure

On 1/17/14 6:28 PM, "Paul Hargrove" mailto:phhargr...@lbl.gov>> wrote: I am trying to build the 1.7 nightly tarball (1.7.4rc2r30303) on a Linux/PPC system with the xlc-11.1 compilers configured for 32-bit output: $ export OBJECT_MODE=32 $ [pathto]/configure CC=xlc CXX=xlC FC=xlf90 --enable-debu

Re: [OMPI devel] [EXTERNAL] 1.7.4rc: build failure on mips32

On 1/17/14 8:00 PM, "Paul Hargrove" mailto:phhargr...@lbl.gov>> wrote: Trying to build 1.7.4rc2r30303 with gcc on linux/mips32 yields the following failure: CXX mpicxx.lo /home/phargrov/OMPI/openmpi-1.7.4-latest-linux-mips32/openmpi-1.7.4rc2r30303/ompi/mpi/cxx/mpicxx.cc:31:2: warning: #

Re: [OMPI devel] [EXTERNAL] Re: bug in mca framework?

PML and I see such >call in ompi_mpi_init() as ".. ret = MCA_PML_CALL(add_procs(procs, >nprocs));...". Moreover BML add_procs() is called by SPML (OSHMEM`s PML) >in oshmem_shmem_init(). >So it looks that all should be correct. Or am I still missing something? > >Igor > >O

Re: [OMPI devel] [EXTERNAL] Re: bug in mca framework?

make it >clearer and review modified patch (I have figured out issue in my >previous patch as absence of complete btl initialization in case PML >components different from bfo and ob1 needed for OSHMEM.) > >Igor > >On 03.01.2014 00:04, Barrett, Brian W wrote: >> Igor - >>

Re: [OMPI devel] [EXTERNAL] RFC: async modex

Is there any place that this can actually be used? It's a fairly large change to the RTE interface (which we should try to keep stable), and I can't convince myself that it's useful; in general, if a BTL or MTL is asking for a piece of data, the MPI library is stuck until that data's available. I

Re: [OMPI devel] [EXTERNAL] Re: 1.7.4rc2r30168 - configure failure on Mac OSX 10.5

Agreed, let's drop 10.5. I don't want to fix that bug given it's likely customer base... Brian Sent with Good (www.good.com) -Original Message- From: Ralph Castain [r...@open-mpi.org] Sent: Friday, January 10, 2014 08:14 AM Mountain Standard Time To: Open MP

Re: [OMPI devel] [EXTERNAL] Re: MX and PSM in 1.7.4

I'm not actually sure about MX. I was testing, but since the last release our machine has been retired. So it's possible we're missing coverage there. Brian Sent with Good (www.good.com) -Original Message- From: Ralph Castain [r...@open-mpi.org] Sent: Thursd

Re: [OMPI devel] [EXTERNAL] Re: bug in mca framework?

Brian On 12/23/13 3:49 AM, "Igor Ivanov" wrote: >Brian, > >Could you look at patch based on your suggestion. It resolves the issue >with mca variable. > >Igor > >On 18.12.2013 01:48, Barrett, Brian W wrote: >> The proposed solution at the bottom is wrong.

Re: [OMPI devel] [EXTERNAL] Re: 1.7.4rc2r30031 - FreeBSD-9 mpirun hangs

I'm guessing that this is related to the threading changes that came with some ORTE changes between 1.7.3 and 1.7.4. I'm building a FreeBSD VM to see if I can make some progress on that, but I live in the land of slow bandwidth, so it might not be for a couple days. Brian On 12/20/13 5:00 PM, "P

Re: [OMPI devel] [EXTERNAL] 1.7.4rc2r30031 - OpenBSD-5 mpirun hangs

Paul - Any chance you could grab a stack trace from the mpi app? That's probably the fastest next step Brian Sent with Good (www.good.com) -Original Message- From: Paul Hargrove [phhargr...@lbl.gov] Sent: Friday, December 20, 2013 03:33 PM Mountain Standar

Re: [OMPI devel] [EXTERNAL] Re: RFC: remove opal progress recursion depth counter

Nathan - Any chance you can remove the two counters this afternoon? Brian On 12/19/13 10:01 AM, "Jeff Squyres (jsquyres)" wrote: >I think there's no problem with removing them from the dll code -- that >stuff doesn't affect MPI application ABI. > > >On Dec 1

Re: [OMPI devel] [EXTERNAL] Consequence of bind-to-core by default

That worked for me. Brian On 12/19/13 9:32 AM, "Ralph Castain" wrote: > > > >Okay, I think I have these things fixed in r29978 on the trunk - please >give it a spin and confirm so we can move it to 1.7.4 > > > >On Dec 19, 2013, at 7:54 AM, Barrett, Bri

Re: [OMPI devel] [EXTERNAL] Consequence of bind-to-core by default

On 12/19/13 8:43 AM, "Ralph Castain" wrote: > >On Dec 19, 2013, at 6:27 AM, Barrett, Brian W wrote: > >> On 12/19/13 6:59 AM, "Jeff Squyres (jsquyres)" >>wrote: >> >>> 3. Finally, we're giving a warning saying: >>> >>

Re: [OMPI devel] [EXTERNAL] Re: RFC: remove opal progress recursion depth counter

Someone who understands the mpi debugging handles code: The opal_progress_recursion_depth_counter and opal_progress_thread_counter are both only used internally in opal_progress (for book keeping, but never any decisions) and are declared in ompi_mpihandles_dll.c, but then don't appear to be used.

Re: [OMPI devel] [EXTERNAL] Consequence of bind-to-core by default

On 12/19/13 6:59 AM, "Jeff Squyres (jsquyres)" wrote: >3. Finally, we're giving a warning saying: > >- >WARNING: a request was made to bind a process. While the system >supports binding the process itself, at least one node does NOT >support binding memory to the process location. >- > >F

Re: [OMPI devel] [EXTERNAL] Re: bug in mca framework?

The proposed solution at the bottom is wrong. There aren't two different BMLs, there's one, and it lives in OMPI. The solution is to open the bml and btls in ompi_mpi_init and not in the pmls. I checked, and the bml will deal with add_procs being called multiple times on the same proc, so just m

Re: [OMPI devel] [EXTERNAL] Re: IB tests in OSHMEM

ke Dubman mailto:mi...@dev.mellanox.co.il>> wrote: Hi, In our internal oshmem v1.7 based branch it is in oshmem/config/oshmem_configure_options.m4 and not in config/oshmem_configure_options.m4 Is that a way to go to have it under oshmem/config? Will check why it is missing. Thanks M On

[OMPI devel] IB tests in OSHMEM

Mellanox - In cleaning up some code, I noticed that the OSHMEM_SETUP_CFLAGS test is testing for infiniband libraries and then linking them into the OSHMEM library. This is fairly different than what we do for the MPI layer; is there a reason those tests are in the top-level configure and not in a

[OMPI devel] Configure refactor branch / merge

Hi all - As some of you know, I've been working on refactoring the configure script to be a bit more friendly to our multi-project approach. I'm relatively happy with where I ended up and would like to merge it into the trunk next week. The biggest change is in the OMPI_MCA macro; it's now per-p

Re: [OMPI devel] [EXTERNAL] Re: [OMPI svn] svn:open-mpi r29733 - in trunk: config oshmem

On 11/24/13 8:00 AM, "Mike Dubman" mailto:mi...@dev.mellanox.co.il>> wrote: But how it will work once oshmem/ folder will be merged into existing folders layout and will not have common root for all shmem files? That will be more complicated; we'll discuss that when we get there, but we'll dis

Re: [OMPI devel] [EXTERNAL] Re: [OMPI svn] svn:open-mpi r29733 - in trunk: config oshmem

I'm pretty sure I was clear it's a hack. But removing from subdirs is how we disable a project, not by adding a big fixed around a makefile (see ORTE). Brian Sent with Good (www.good.com) -Original Message- From: Mike Dubman [mi...@dev.mellanox.co.il]

Re: [OMPI devel] [EXTERNAL] Re: Change request for include/mpif-config.h

David (Gunter) - Which version of Open MPI are you using? It looks like the 1.7 series does not declare the internal version (GREEK / SVN) in the Fortran headers, so this shouldn't be a problem going forward. Brian On 11/22/13 8:39 AM, "Dave Goodell (dgoodell)" wrote: >Jeff Squyres is usually

Re: [OMPI devel] [EXTERNAL] Re: [OMPI svn-full] svn:open-mpi r29703 - in trunk: contrib/platform/iu/odin ompi/mca/btl/openib ompi/mca/btl/openib/connect

On 11/14/13 1:13 PM, "Joshua Ladd" wrote: >Let me try to summarize my understanding of the situation: > >1. Ralph made the OOB asynchronous. > >2. OOB cpcs don't work as a result of 1, and are thereby "deprecated", >meaning: won't fix. > >3. Pasha moved the openib/connect to common/ofacm but excl

Re: [OMPI devel] [EXTERNAL] What to do about openib/ofacm/cpc (was: r29703 - in trunk: contrib/p...)

On 11/14/13 11:16 AM, "Jeff Squyres (jsquyres)" wrote: >On Nov 14, 2013, at 1:03 PM, Ralph Castain wrote: > >>> 1) What the status of UDCM is (does it work reliably, does it support >>> XRC, etc.) >> >> Seems to be working okay on the IB systems at LANL and IU. Don't know >>about XRC - I seem t

Re: [OMPI devel] [EXTERNAL] Re: [OMPI svn-full] svn:open-mpi r29703 - in trunk: contrib/platform/iu/odin ompi/mca/btl/openib ompi/mca/btl/openib/connect

On 11/14/13 9:51 AM, "Jeff Squyres (jsquyres)" wrote: >Does XRC work with the UDCM CPC? > > >On Nov 14, 2013, at 9:35 AM, Ralph Castain wrote: > >> I think the problems in udcm were fixed by Nathan quite some time ago, >>but never moved to 1.7 as everyone was told that the connect code in >>open

Re: [OMPI devel] [EXTERNAL] Re: [OMPI svn-full] svn:open-mpi r29651 - in trunk: config examples oshmem/include oshmem/tools/oshmem_info

On 11/11/13 12:49 PM, "Jeff Squyres (jsquyres)" wrote: >More comments on this commit: > >- The Fortran, Java, and C++ MPI examples are now no longer build by >default. Er... what happened there, and why? > >- Why are the oshmem examples in a separate target? The point of the >previous makefile

Re: [OMPI devel] [EXTERNAL] Re: [OMPI svn] svn:open-mpi r29633 - in trunk: . contrib contrib/dist/linux contrib/dist/linux/debian contrib/dist/linux/debian/source

On 11/7/13 11:15 AM, "Jeff Squyres (jsquyres)" wrote: >On Nov 7, 2013, at 9:10 AM, Ralph Castain wrote: > >>> how it is differ from other related stuf kept in svn to support: >>> >>> - rpm based distros? (dist/linux/) >>> - macos (contrib/dist/macosx-pkg/) >>> - __debian_stuff_could_be_here_as_

Re: [OMPI devel] [EXTERNAL] Re: [OMPI svn-full] svn:open-mpi r29615 - in trunk: . contrib contrib/dist/linux debian debian/source

On 11/6/13 4:07 PM, "Ralph Castain" wrote: >Afraid I couldn't parse that debian link - no idea what any of it meant, >and there was no identified problem listed there. There's a bugs column you can click on the find the list of outstanding bugs. >My concern here is that we seem to be putting so

Re: [OMPI devel] [EXTERNAL] Re: portable_platform.h copies

On 11/6/13 7:44 AM, "Jeff Squyres (jsquyres)" wrote: >I looked at that, too -- I think the only reason to have 2 files is that >mpi_portable_platform.h is included by mpi.h (its used for knowing how to >define __mpi_interface_deprecated__ in mpi.h), and is therefore >installed. opal_portable_pla

[OMPI devel] portable_platform.h copies

All - Is there a reason we have both opal/include/opal_portable_platform.h and ompi/include/mpi_portable_platform.h? If they're always supposed to have the same content (which appears to be the case), then it seems like building mpi_portable_platform.h from opal_portable_platform.h at build time

[OMPI devel] debian/ directory

Hi all - Mike added a debian/ directory to the top-level of the tree this morning, which looks to be helping in building a Debian package. While I don't mind helping Debian, I'm really against having a debian/ directory in our top-level tree. We have a place for those things (in contrib/). If D

Re: [OMPI devel] [EXTERNAL] Re: oshmem and CFLAGS removal

On 10/31/13 2:42 PM, "Rolf vandeVaart" wrote: >>-Original Message- >>From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Jeff Squyres >>(jsquyres) >>Sent: Thursday, October 31, 2013 4:12 PM >>To: Open MPI Developers >>Subject: Re: [OMPI devel] oshmem and CFLAGS removal >> >>On Oc

[OMPI devel] CM PML / OpenSHMEM

Mellanox - It looks like someone fixed the segfault when calling start_pes() when the CM PML is in use. However, I'm not sure that a clean abort is much better. With the proc tags code (in both the trunk and v1.7), there's no reason that you can't initialize both the btls and mtls. This may req

Re: [OMPI devel] [EXTERNAL] Re: SHMEM v1.7 merge proposal

s exactly the way we handle it now. We have internal branch on top of > v1.7 with all SHMEM code in it. > It runs mtt and other tests. > > Once we done with all changes - we will provide patch (and branch direct > access if needed) for GK. > > Kind Regards > Mike. > > &

Re: [OMPI devel] [EXTERNAL] Re: SHMEM v1.7 merge proposal

1.7 with all SHMEM code in it. > It runs mtt and other tests. > > Once we done with all changes - we will provide patch (and branch direct > access if needed) for GK. > > Kind Regards > Mike. > > > On Tue, Oct 29, 2013 at 1:02 AM, Barrett, Brian W > mailto:bwba

[OMPI devel] SHMEM v1.7 merge proposal

All - Ralph and I talked today about the logistics of bringing the OpenSHMEM code to the 1.7 release branch, as it's now a fairly large set of changes from the trunk. What we propose is to follow the same proceedure we used when merging in the RTE framework change, which is essentially a staging

Re: [OMPI devel] [EXTERNAL] Re: shmem vs. oshmem

ld help us to maintain better transition support if both names will >be available for some defined period of time. > > >Thanks > > > > > >On Mon, Oct 28, 2013 at 9:13 PM, Barrett, Brian W > wrote: > >What's the advantage of that approach? You're a

Re: [OMPI devel] [EXTERNAL] Re: shmem vs. oshmem

ince me. Brian On 10/28/13 1:08 PM, "Mike Dubman" wrote: >I would prefer to keep both names for a while and depricate them >gradually. >I suggest to release 1st drop with both namings and drop legacy right >after that. > > > > >On Mon, Oct 28, 2013 at 8:22 P

Re: [OMPI devel] [EXTERNAL] Re: shmem vs. oshmem

, 2013, at 1:03 PM, Mike Dubman > wrote: > >> Thanks Brian, >> The code in trunk already generates: >> >> oshccoshfort oshmem_info oshrun >> >> >> On Sat, Oct 26, 2013 at 12:13 AM, Barrett, Brian W >>wrote: >> i thought I me

Re: [OMPI devel] [EXTERNAL] Re: shmem vs. oshmem

i thought I mentioned this before, but the compilers should be oshcc, oshCC, and oshfort, with the starter named oshrun, according to Appendix C of the spec. Brian -- Brian W. Barrett Scalable System Software Group Sandia National Laboratories From:

Re: [OMPI devel] [EXTERNAL] 1.7.x support statement

the Solaris >support be in the lightly tested category? I see only the 32-bit Solaris >entry, with everything else still shown in the "full" category > > >On Oct 6, 2013, at 7:22 PM, "Barrett, Brian W" wrote: > >> I agree with the Solaris move. >>

Re: [OMPI devel] [EXTERNAL] 1.7.x support statement

I agree with the Solaris move. Brian On 10/4/13 5:08 AM, "Jeff Squyres (jsquyres)" wrote: >This is in the README -- is it still accurate? I'm thinking that all >Solaris support should move to the "lightly but not fully tested" >category, for example: > >- >- Systems that have been tested a

Re: [OMPI devel] [EXTERNAL] Dev meeting

On 10/5/13 6:34 AM, "Jeff Squyres (jsquyres)" wrote: >Sam - We didn't come to consensus here in the list about a date/location >for a dev meeting. > >Can you add it to Tuesdays agenda? I unfortunately won't be able to make it to the Tuesday meeting. I'm pretty flexible about scheduling for the

Re: [OMPI devel] [EXTERNAL] Re: OMPI dev meeting: December?

-Dave >>>> >>>> On Oct 1, 2013, at 11:30 AM, Nathan Hjelm wrote: >>>> >>>>> Ok, that should be fine. Its a long way to MDW on the L (> 1 hr) but >>>>>it can't be helped. >>>>> >>>>> -Nathan >>>

Re: [OMPI devel] [EXTERNAL] Re: OMPI dev meeting: December?

On 10/1/13 9:46 AM, "Nathan Hjelm" wrote: > >On Tue, Oct 01, 2013 at 03:42:15PM +, Jeff Squyres (jsquyres) wrote: >> Ralph brought up the idea of a face-to-face developers meeting >>yesterday. How about piggybacking on the December Chicago MPI Forum >>meeting? >> >> 1. The Forum starts 1pm

Re: [OMPI devel] [EXTERNAL] Re: OpenSHMEM failures

Playing some more, it looks like the error only occurs with --enable-mpi-thread-multiple. Apparently, no one tried to test with thread multiple? Brian On 9/25/13 1:28 PM, "Barrett, Brian W" wrote: >Yes, with r29246. > >Brian > >On 9/25/13 1:26 PM, "Ralph Cas

Re: [OMPI devel] [EXTERNAL] Re: OpenSHMEM failures

Yes, with r29246. Brian On 9/25/13 1:26 PM, "Ralph Castain" wrote: >Is this with current head? Josh committed a fix yesterday that I thought >addressed these > >On Sep 25, 2013, at 12:02 PM, "Barrett, Brian W" >wrote: > >> Guys - >> >>

[OMPI devel] OpenSHMEM failures

Guys - I think this was mentioned already, but I'm still seeing failures in the trunk building the SHMEM code (below). RHEL 6.4, GCC 4.4.7, 64 bit build. CC spml_yoda.lo cc1: warnings being treated as errors spml_yoda.c: In function 'mca_yoda_get_callback': spml_yoda.c:231: error: pointe

Re: [OMPI devel] [EXTERNAL] Re: [OMPI users] Error in openmpi-1.9a1r29179

I agree on the shmem.fh statements. There are a couple of really painful interfaces to prototype, but for the most part, it should be straight forward. There's nothing in the OpenSHMEM specification that suggests providing a Fortran module, so I believe you got bad advice there. Brian -- B

Re: [OMPI devel] [EXTERNAL] oshmem implementation still lacking

-boun...@open-mpi.org] on behalf of Jeff Squyres (jsquyres) [jsquy...@cisco.com] Sent: Sunday, September 15, 2013 4:13 AM To: Open MPI Developers Subject: Re: [OMPI devel] [EXTERNAL] oshmem implementation still lacking On Sep 15, 2013, at 12:10 PM, "Barrett, Brian W" wrote: > Ar

Re: [OMPI devel] [EXTERNAL] oshmem implementation still lacking

Sorry for the top-reply; Outlook webmail sucks. Are the wrapper compilers named shmem? Given that the OpenSHMEM specification specifically calls out the name of the wrapper compilers as osh, we should probably follow that convention. Brian -- Brian W. Barrett Scalable System Software Grou

Re: [OMPI devel] [EXTERNAL] OpenSHMEM round 2

On 8/15/13 10:30 AM, "George Bosilca" wrote: > >On Aug 15, 2013, at 18:06 , Joshua Ladd wrote: > >> Maybe this is a stupid question, but in this case (I believe this goes >>all the way back to our initial discussion on OSHMEM), how does one fall >>back onto send/recv semantics when the call is m

Re: [OMPI devel] [EXTERNAL] OpenSHMEM round 2

;observed are we on a good course to getting this upstream? Is it >reasonable to file an RFC for three weeks out? > >Josh > >-----Original Message- >From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Barrett, >Brian W >Sent: Sunday, August 11, 2013 1:42 PM >

Re: [OMPI devel] [EXTERNAL] OpenSHMEM round 2

#x27; differ in signedness >> ../../../../opal/include/opal/sys/amd64/atomic.h:174: note: expected >>'volatile int32_t *' but argument is of type 'uint32_t *' >> spml_yoda.c:1107: error: signed and unsigned type in conditional >>expression >> make[2]: **

Re: [OMPI devel] [EXTERNAL] OpenSHMEM round 2

On 8/6/13 10:30 AM, "Joshua Ladd" wrote: >Dear OMPI Community, > >Please find on Bitbucket the latest round of OSHMEM changes based on >community feedback. Please git and test at your leisure. > >https://bitbucket.org/jladd_math/mlnx-oshmem.git Josh - In general, I think everything looks ok.

[OMPI devel] v1.7 RTE testing / changes

Hi all - As some of you probably noticed, we brought the RTE framework changes from the trunk to v1.7 this morning. This is a big change, but should help with some of the merge conflicts we've been seeing (we're also going to move the config/ directories to match the trunk). We did a bunch of

Re: [OMPI devel] [EXTERNAL] Re: RFC: Change ompi_proc_t endpoint data lookup

On 7/22/13 9:19 AM, "David Goodell (dgoodell)" wrote: >On Jul 20, 2013, at 4:42 PM, "Barrett, Brian W" >wrote: > >> On 7/20/13 3:33 PM, "George Bosilca" wrote: >> >>> - In terms of memory this solution provide an approach where ther

Re: [OMPI devel] [EXTERNAL] Re: RFC: Change ompi_proc_t endpoint data lookup

On 7/20/13 3:33 PM, "George Bosilca" mailto:bosi...@icl.utk.edu>> wrote: - The cost of accessing the endpoints will be a load from the ompi_proc_t to get that global index and then another relative load (using this index and the array of endpoints). So exactly the same number of loads as the d

Re: [OMPI devel] [EXTERNAL] Re: RFC: Change ompi_proc_t endpoint data lookup

On 7/19/13 10:58 AM, "George Bosilca" wrote: >1. The BML endpoint structure (aka. BML proc) is well known and defined >in the bml.h. So it is not technically opaqueŠ It's opaque in that outside of the R2 BML, users were not supposed to poke at what's in proc_bml without using the BML interface.

Re: [OMPI devel] [EXTERNAL] Re: RFC: Change ompi_proc_t endpoint data lookup

On 7/18/13 7:39 PM, "Ralph Castain" mailto:r...@open-mpi.org>> wrote: We are looking at exascale requirements, and one of the big issues is memory footprint. We currently retrieve the endpoint info for every process in the job, plus all the procs in any communicator with which we do a connect/a

[OMPI devel] RFC: Change ompi_proc_t endpoint data lookup

What: Change the ompi_proc_t endpoint data lookup to be more flexible Why: As collectives and one-sided components are using transports directly, an old problem of endpoint tracking is resurfacing. We need a fix that doesn't suck. When: Assuming there are no major objections, I'll start writing

Re: [OMPI devel] [EXTERNAL] Annual OMPI membership review: SVN accounts

On 7/8/13 4:32 PM, "Jeff Squyres (jsquyres)" wrote: >According to >https://svn.open-mpi.org/trac/ompi/wiki/Admistrative%20rules, it is time >for our annual review of Open MPI SVN accounts of these SVN repos: hwloc, >mtt, ompi-docs, ompi-tests, ompi-www, ompi. > >*** Organizations must reply by C

Re: [OMPI devel] [EXTERNAL] RFC: OMPI_FREE_LIST_{GET|WAIT} lose the rc argument

tch like this a while ago, and it met violent >>resistance. :-) Although no one on the call today remembers exactly >>who raised the resistance... >> >> >> >> On Jul 2, 2013, at 10:40 AM, "Barrett, Brian W" >>wrote: >> >>>

[OMPI devel] RFC: Remove Darwin backtrace support

All - I would like to remove the Darwin backtrace component. Since 10.5.0, OS X has supported the execinfo() interface supported by Linux, which is both easier to use and less fragile. So the impact will be a loss of stack traces on failure on OS X versions prior to 10.5.0, which should be a sma

Re: [OMPI devel] [EXTERNAL] RFC: OMPI_FREE_LIST_{GET|WAIT} lose the rc argument

On 7/2/13 8:22 AM, "George Bosilca" wrote: > Our macros for the OMPI-level free list had one extra argument, a possible > return value to signal that the operation of retrieving the element from the > free list failed. However in this case the returned pointer was set to NULL as > well, so the er

Re: [OMPI devel] [EXTERNAL] Re: aclocal-1.14: error: ../../config/autogen_found_items.m4:274: file 'opal/mca/backtrace/configure.m4' does not exist

On 7/1/13 9:52 AM, "Joshua Ladd" wrote: >I think we (MLNX) are getting corrupted/truncated checkouts. Lately, I >have been running into the following error on our internal systems when >doing a secure checkout: > >svn co https://svn.open-mpi.org/svn/ompi/trunk ompi-trunk > >svn: E175002: REPORT o

Re: [OMPI devel] [EXTERNAL] Re: RFC: support for Mellanox's "libhcoll" library

In general, I'm ok with it. I think we should let it soak for a week or two in the trunk before we file the CMR to 1.7. Brian On 6/18/13 6:51 AM, "Jeff Squyres (jsquyres)" wrote: >Sounds good; +1. > >On Jun 18, 2013, at 8:02 AM, Joshua Ladd wrote: > >> Request for Change: >> >> What: Add su

Re: [OMPI devel] [EXTERNAL] glibc malloc hooks going away

On 6/10/13 8:23 AM, "Jeff Squyres (jsquyres)" wrote: >If you saw Mellanox's commit this morning, you noticed a comment about >how the glibc malloc hooks are deprecated. I pinged Mike D. about this >off-list, and he sent me the following reference from the glibc 2.14 >release notes at >http://so

Re: [OMPI devel] [EXTERNAL] Re: RFC: Python-generated Fortran wrappers

On 5/22/13 9:35 AM, "Ralph Castain" wrote: >* this isn't about Craig and his abilities - this is a more general >requirements discussion. I personally wouldn't change my comments if it >was Jeff or Brian making the request - the issue remains the same. >Introducing another language requirement on

Re: [OMPI devel] [EXTERNAL] Re: Porting Open MPI

On 5/22/13 6:54 AM, "Ralph Castain" wrote: >On May 22, 2013, at 4:55 AM, jhonatan alves >wrote: > >> >> Hello, >> We are trying port Open MPI to a new operating system, called EPOS, but >>our main problem at the moment is that this operating system is not >>POSIX compatible. > >That could make

Re: [OMPI devel] [EXTERNAL] Re: RFC: Python-generated Fortran wrappers

On 5/22/13 6:50 AM, "Ralph Castain" wrote: > >On May 22, 2013, at 6:37 AM, "Jeff Squyres (jsquyres)" > wrote: > >> On May 22, 2013, at 9:18 AM, Ralph Castain wrote: >> >>> I have no issues other than wondering why we don't do it in perl given >>>that we already do all non-shell actions in perl

Re: [OMPI devel] [EXTERNAL] Developer meeting: mid/late summer?

I could probably do Monday afternoon and Tuesday morning? The problem with Friday afternoon is that it means I can't grab the Friday afternoon flights home and have to stay until Saturday. Monday afternoon / Tuesday morning would mean no weekend travel. Brian -- Brian W. Barrett Scalable

[OMPI devel] Open MPI 1.7rc9 tarballs up

All - What we dearly hope is the final release candidate of 1.7, 1.7rc9,is up at the usual place. I would really like to release this early next week, so if we could all test, that would be great. http://www.open-mpi.org/software/ompi/v1.7/ Thanks! Brian -- Brian W. Barrett Scalable Sy

[OMPI devel] Linux memory hooks testing

All - In an effort to get 1.7 out the door, I'm asking that everyone who cares tries the memory hooks on Linux to make sure they work as expected on the trunk. That is, if you rely on leave pinned, make sure you get the bandwidth you expect. If you don't, make sure things compile in all your com

Re: [OMPI devel] [EXTERNAL] Re: [OMPI svn] svn:open-mpi r28202 - in trunk: ompi/runtime opal/mca/memory/linux

On 3/22/13 9:53 AM, "Barrett, Brian W" wrote: >On 3/22/13 9:35 AM, "Ralph Castain" wrote: > >>On Mar 22, 2013, at 8:23 AM, "Barrett, Brian W" >>wrote: >> >>> On 3/22/13 9:17 AM, "Ralph Castain" wrot

Re: [OMPI devel] [EXTERNAL] Re: [OMPI svn] svn:open-mpi r28202 - in trunk: ompi/runtime opal/mca/memory/linux

On 3/22/13 9:35 AM, "Ralph Castain" wrote: >On Mar 22, 2013, at 8:23 AM, "Barrett, Brian W" >wrote: > >> On 3/22/13 9:17 AM, "Ralph Castain" wrote: >> >>> I'm afraid this still doesn't work for me - on my Cent

Re: [OMPI devel] [EXTERNAL] Re: [OMPI svn] svn:open-mpi r28202 - in trunk: ompi/runtime opal/mca/memory/linux

On 3/22/13 9:17 AM, "Ralph Castain" wrote: >I'm afraid this still doesn't work for me - on my Centos box: > >../../../ompi/.libs/libmpi.so: undefined reference to >`opal_memory_linux_malloc_init_hook' > >I tried it with a brand new checkout of the trunk. Any ideas? Can you run nm on the built li

[OMPI devel] RFC: Remove solaris thread support

Hi all - I'd like to propose that we remove the support for Solaris threads in the trunk. Solaris provides a pthread implementation which is of equivalent performance and supporting two thread libraries is kind of a pain. Pthreads also supports static initializers, which will be nice going forwar

Re: [OMPI devel] [EXTERNAL] Re: [OMPI svn] svn:open-mpi r28016 - trunk/ompi/mca/btl/tcp

t I have on some machines, >every single MPI job hung because they tried to use those interfaces to >communicate with processes on other nodes that that interface could not >reach. > > > >On Feb 4, 2013, at 5:56 PM, "Barrett, Brian W" wrote: > >> I'm confused

Re: [OMPI devel] [EXTERNAL] Re: [OMPI svn] svn:open-mpi r28016 - trunk/ompi/mca/btl/tcp

I'm confused; why is it disastrous to have an interface in if_exclude that doesn't exist? I can see it being a problem if we don't exclude something in the list, but the other way is (in my opinion) harmless but with a useful use case... Brian Sent with Good (www.good.com) -Original

Re: [OMPI devel] [EXTERNAL] Re: [OMPI svn] svn:open-mpi r28016 - trunk/ompi/mca/btl/tcp

I don't think this is right either. Excluding a device that doesn't exist has many use cases. Such as disabling a network that only exists on part of the cluster. I'm not sure about what to do with seq; it's more like include than exclude. Brian Sent with Good (www.good.com) -Origina

Re: [OMPI devel] [EXTERNAL] trunk install failure [brbarret]

Thanks for noticing this. Fixed in the trunk. Brian On 1/28/13 11:15 PM, "Paul Hargrove" wrote: > Using tonight's trunk tarball (r27954) configured using "--with-devel-headers" > it looks like "make install" is trying to install rte_orte.h TWICE: > >> /usr/bin/install -c -m 644 ../../../../

Re: [OMPI devel] [EXTERNAL] Open MPI Configure Script

On 1/28/13 11:54 AM, "David Beer" wrote: > checking for tm_init in -ltorque... no > configure: error: TM support requested but not found. Aborting > > Oddly enough, if you have already configured with an older version of TORQUE, > you can build open-mpi with TORQUE 4.2 installed, so it can find

Re: [OMPI devel] [EXTERNAL] Open MPI Configure Script

On 1/28/13 10:50 AM, "David Beer" wrote: > By way of introduction, I'm a TORQUE developer and I probably should've joined > this list - even if only to keep myself informed - years ago. > > At any rate, we're in the process of changing TORQUE so that it compiles using > g++ instead of gcc. We're

Re: [OMPI devel] [EXTERNAL] Re: RTE Framework

l of granularity one can bring in additional capabilities. >> I have not looked in detail yet, but will in the near future. >> >> Thanks, >> Rich >> >> -Original Message- >> From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] On &g

[OMPI devel] RFC: RTE Framework

Hi all - As discussed at the December developer's meeting, a number of us have been working on a framework in OMPI to encompass the RTE resources (typically provided by ORTE). This follows on work Oak Ridge did on the ORCA layer, which ended up having a number of technical challenges and was drop

[OMPI devel] bcol basesmuma maintainer?

Hi all - Who's maintaining the bcol basesmuma component? I'd like to commit the attached patch, which cleans up some usage of process names, but want a second pair of eyeballs. The orte_namelist_t type is meant for places where the orte_process_na me_t needs to be put on a list. In basesmuma, i

Re: [OMPI devel] [EXTERNAL] RFC: Enable thread support by default

read support by default On Dec 10, 2012, at 10:35 AM, "Barrett, Brian W" wrote: > On 12/10/12 11:25 AM, "Ralph Castain" wrote: > >> >> On Dec 10, 2012, at 10:15 AM, "Barrett, Brian W" >> wrote: >> >>> On 12/8/12 7:59 PM, "

Re: [OMPI devel] [EXTERNAL] RFC: Enable thread support by default

On 12/10/12 11:25 AM, "Ralph Castain" wrote: > >On Dec 10, 2012, at 10:15 AM, "Barrett, Brian W" >wrote: > >> On 12/8/12 7:59 PM, "Ralph Castain" wrote: >> >>> WHAT:Enable both OPAL and libevent thread support by default >

Re: [OMPI devel] [EXTERNAL] RFC: Enable thread support by default

On 12/8/12 7:59 PM, "Ralph Castain" wrote: >WHAT:Enable both OPAL and libevent thread support by default > >WHY: We need to support threaded operations for MPI-3, and for >MPI_THREAD_MULTIPLE. > Enabling thread support by default is the only way to >ensure we fix all the

Re: [OMPI devel] [EXTERNAL] Re: [OMPI svn] svn:open-mpi r27580 - in trunk: ompi/mca/btl/openib ompi/mca/btl/wv ompi/mca/coll/ml opal/util/keyval orte/mca/rmaps/rank_file

We should never have to have the makefile extension. Just making sure the lex file gets included should work. When Nathan commits his patch, I'll take a look. Brian Sent with Good (www.good.com) -Original Message-

Re: [OMPI devel] [EXTERNAL] Re: running top-level autogen.sh breaks romio in 1.6.3 tarball

David - Thanks for the bug report; the missing file will be in the tarball of the next release. Brian On 10/31/12 3:15 PM, "David Shrader" wrote: >Hello, > >Thank you for the reply! All of the autotools I am using have the same >or higher versions than those specified at >http://www.open-mpi.o

Re: [OMPI devel] [EXTERNAL] Re: running top-level autogen.sh breaks romio in 1.6.3 tarball

I don't think this is actually old autotools, since those are the most recent. My guess is that there's an m4 file not being included in the tarball. I'll try to take a look, but we probably need to fix a Makefile in ROMIO. Brian On 10/31/12 2:46 PM, "Ralph Castain" wrote: >We've seen this be

Re: [OMPI devel] [EXTERNAL] Re: Compile-time MPI_Datatype checking

On 10/31/12 1:57 PM, "Dmitri Gribenko" wrote: >On Wed, Oct 31, 2012 at 9:51 PM, Barrett, Brian W >wrote: >> On 10/31/12 1:39 PM, "Paul Hargrove" wrote: >> >>>No, I don't have specific usage cases that concern me. >>> >>> &g

Re: [OMPI devel] [EXTERNAL] Re: Compile-time MPI_Datatype checking

On 10/31/12 1:39 PM, "Paul Hargrove" wrote: >No, I don't have specific usage cases that concern me. > > >As I said a minute or two ago in a reply to Ralph, my concern is that the >Sandia codes provide an "existence proof" that "really smart people" can >write questionable code at times. So, I fe

Re: [OMPI devel] [EXTERNAL] Re: Latency perf: v1.6 vs. v1.7 vs. trunk

On 10/25/12 10:55 AM, "Jeff Squyres" wrote: >Something that might not be clear from my initial writeup: > >1. I had to go change C code to disable libnbc. Since non-blocking >collectives are part of MPI-3: > a) we have no convenient configure argument to not build the libnbc >coll component (t

[OMPI devel] MX BTL segfaults

Hi all - The MX BTL segfaults during MPI_FINALIZE in the trunk (and did before my mpool change in r27485). I'm not really interested in fixing it; the problem does not occur with the MX MTL. Does anyone else have interest in fixing it? If not, should we remove it from the trunk (we already remo

Re: [OMPI devel] [EXTERNAL] Re: Latency perf: v1.6 vs. v1.7 vs. trunk

Your first e-mail got eaten by our virus scanner (it doesn't like .bz2 files), but we could probably only register the libnbc progress function on first use, but it would slightly slow down all non blocking collectives. Probably worth it, but not sure I'll have time to add that code today. Brian

  1   2   3   >