[hwloc-devel] Create success (hwloc git dev-31-g4c0ce9e)

Creating nightly hwloc snapshot git tarball was a success. Snapshot: hwloc dev-31-g4c0ce9e Start time: Wed Dec 18 21:01:01 EST 2013 End time: Wed Dec 18 21:04:00 EST 2013 Your friendly daemon, Cyrador

Re: [OMPI devel] Q: MPI-RTE / ompi_proc_t vs. ompi_process_info_t ?

Hi Ralph, OK, thanks for clarification and code pointers. I'll update "rte.h" to reflect the updates. Thanks, --tjn _ Thomas Naughton naught...@ornl.gov Research Associate

Re: [OMPI devel] Recommended tool to measure packet counters

Ah got it ! Thanks -- Sid On 18 December 2013 07:44, Jeff Squyres (jsquyres) wrote: > On Dec 14, 2013, at 8:02 AM, Siddhartha Jana > wrote: > > > Is there a preferred method/tool among developers of MPI-library for > checking the count of the

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

Opps, yeah. Meant 1.7.5. If people agree with this change I could possibly slip it in before Friday but that is unlikely. On Wed, Dec 18, 2013 at 03:32:36PM -0800, Ralph Castain wrote: > U1.7.4 is leaving the station on Fri, Nathan, so next Tues => will > have to go into 1.7.5 > > > On

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

U1.7.4 is leaving the station on Fri, Nathan, so next Tues => will have to go into 1.7.5 On Dec 18, 2013, at 3:23 PM, Nathan Hjelm wrote: > What: Remove the opal_progress_recursion_depth_counter from > opal_progress. > > Why: This counter adds two atomic adds to the

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

What: Remove the opal_progress_recursion_depth_counter from opal_progress. Why: This counter adds two atomic adds to the critical path when OPAL_HAVE_THREADS is set (which is the case for most builds). I grepped through ompi, orte, and opal to find where this value was being used and did not find

Re: [OMPI devel] Q: MPI-RTE / ompi_proc_t vs. ompi_process_info_t ?

There is no relation at all between ompi_proc_t and ompi_process_info_t. The ompi_proc_t is defined in the MPI layer and is used in that layer in various places very much like orte_proc_t is used in the ORTE layer. If you look in ompi/mca/rte/orte/rte_orte.c, you'll see how we handle the

[OMPI devel] Q: MPI-RTE / ompi_proc_t vs. ompi_process_info_t ?

Hi Ralph, Question about the MPI-RTE interface change in r29931. The change was not reflected in the "ompi/mca/rte/rte.h" file. I'm curious how the newly added "struct ompi_proc_t" relates to the "struct ompi_process_info_t" that is described in the "rte.h" file? I understand the general

[OMPI devel] Problem with memory in mpi program

My program it is with MPI and OpenMP, and is a sample program take much memory, I don't know the memory RAM consume for a mpi program and I want to know if mpi consume a lot of memory when if used together openmp or I doing something wrong, for take memory Ram of mi program I used a file

Re: [OMPI devel] Bus error with openmpi-1.7.4rc1 on Solaris

Found the problem. Was accessing a boolean variable using intval. That is a bug that has gone unnoticed on all platforms but thankfully Solaris caught it. Please try the attached patch. -Nathan On Wed, Dec 18, 2013 at 12:27:29PM +0100, Siegmar Gross wrote: > Hi, > > today I installed

Re: [OMPI devel] Bus error with openmpi-1.7.4rc1 on Solaris

Siegmar -- Thanks for keeping us honest! I just filed three tickets with the issues you reported: https://svn.open-mpi.org/trac/ompi/ticket/3988 https://svn.open-mpi.org/trac/ompi/ticket/3989 https://svn.open-mpi.org/trac/ompi/ticket/3990 On Dec 18, 2013, at 6:27 AM, Siegmar Gross

Re: [OMPI devel] [PATCH v2 2/2] Trying to get the C/R code to compile again. (send_*_nb)

In the case of the send, there really isn't any problem with just replacing things - the non-blocking change won't impact anything, so no need to retain the old code. People were only concerned about the recv's as those places will require further repair, and they wanted to ensure we know where

Re: [OMPI devel] [PATCH v2 1/2] Trying to get the C/R code to compile again. (recv_*_nb)

Hi Adrian No point in keeping the old code for those places where you update the syntax of a non-blocking recv (i.e., you remove the no-longer-reqd extra param). I would only keep it where you have to replace a blocking recv with a non-blocking one as that is where the behavior will change.

[OMPI devel] [PATCH v2 0/2] Trying to get the C/R code to compile again

From: Adrian Reber This is the second try to replace the usage of blocking send and recv in the C/R code with the non-blocking versions. The new code compiles (in contrast to the old code) but does not work yet. This is the first step to get the C/R code working

[OMPI devel] [PATCH v2 2/2] Trying to get the C/R code to compile again. (send_*_nb)

From: Adrian Reber This patch changes all send/send_buffer occurrences in the C/R code to send_nb/send_buffer_nb. The old code is still there but disabled using ifdefs (ENABLE_FT_FIXED). The new code compiles but does not work. Changes from V1: * #ifdef out the

[OMPI devel] [PATCH v2 1/2] Trying to get the C/R code to compile again. (recv_*_nb)

From: Adrian Reber This patch changes all recv/recv_buffer occurrences in the C/R code to recv_nb/recv_buffer_nb. The old code is still there but disabled using ifdefs (ENABLE_FT_FIXED). The new code compiles but does not work. Changes from V1: * #ifdef out the

Re: [OMPI devel] [patch] async-signal-safe signal handler

This patch looks good to me (sorry for the delay in replying -- MPI Forum + OMPI dev meeting got in the way). Brian -- do you have any opinions on it? On Dec 11, 2013, at 1:43 AM, Kawashima, Takahiro wrote: > Hi, > > Open MPI's signal handler (show_stackframe

Re: [OMPI devel] Recommended tool to measure packet counters

On Dec 14, 2013, at 8:02 AM, Siddhartha Jana wrote: > Is there a preferred method/tool among developers of MPI-library for checking > the count of the packets transmitted by the network card during two-sided > communication? > > Is the use of > iptables -I INPUT -i

[OMPI devel] Bus error with openmpi-1.7.4rc1 on Solaris

Hi, today I installed openmpi-1.7.4rc1 on Solaris 10 Sparc with Sun C 5.12. Unfortunately my problems with bus errors, which I reported December 4th for openmpi-1.7.4a1r29784 at us...@open-mpi.org, are not solved yet. Has somebody time to look into that matter or is Solaris support abandoned, so