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

On 7/18/13 7:39 PM, "Ralph Castain" > 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

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

+1, though I do have a question. 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/accept - even though we probably will

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

+1, but I helped come up with the idea. :-) On Jul 18, 2013, at 5:32 PM, "Barrett, Brian W" wrote: > 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

[hwloc-devel] Create success (hwloc r1.7.2rc1r5731)

Creating nightly hwloc snapshot SVN tarball was a success. Snapshot: hwloc 1.7.2rc1r5731 Start time: Thu Jul 18 21:05:06 EDT 2013 End time: Thu Jul 18 21:08:52 EDT 2013 Your friendly daemon, Cyrador

[hwloc-devel] Create success (hwloc r1.8a1r5730)

Creating nightly hwloc snapshot SVN tarball was a success. Snapshot: hwloc 1.8a1r5730 Start time: Thu Jul 18 21:01:01 EDT 2013 End time: Thu Jul 18 21:05:06 EDT 2013 Your friendly daemon, Cyrador

[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] ompi_info

On Jul 18, 2013, at 11:50 AM, George Bosilca wrote: > How is this part of the code validated? It might capitalize on some type of > "trust". Unfortunately … I have no such notion. Not sure what you're asking here. > I would rather take the path of the "least

Re: [OMPI devel] ompi_info

On Thu, Jul 18, 2013 at 05:50:40PM +0200, George Bosilca wrote: > On Jul 18, 2013, at 17:07 , Nathan Hjelm wrote: > > > This was discussed in depth before the MCA rewrite came into the trunk. > > There are only two cases where we load and register all the available > >

Re: [OMPI devel] KNEM + user-space hybrid for sm BTL

Le 18 juil. 2013 à 11:12, "Iliev, Hristo" a écrit : > Hello, > > Could someone, who is more familiar with the architecture of the sm BTL, > comment on the technical feasibility of the following: is it possible to > easily extend the BTL (i.e. without having to

Re: [OMPI devel] ompi_info

On Thu, Jul 18, 2013 at 08:33:37AM -0700, Ralph Castain wrote: > > On Jul 18, 2013, at 8:17 AM, "David Goodell (dgoodell)" > wrote: > > > On Jul 18, 2013, at 9:53 AM, Ralph Castain wrote: > > > >> On Jul 18, 2013, at 7:05 AM, David Goodell (dgoodell)

Re: [hwloc-devel] upcoming cleaning of headers and doc sections

Just to throw in a wildcard... You could also make hwloc.h be pretty minimal, and #include a bunch of others. You could divide sub-.h files by: - types - section / functionality - ...? On Jul 18, 2013, at 8:09 AM, Brice Goglin wrote: > FYI, I recently got a lot of

Re: [OMPI devel] ompi_info

On Jul 18, 2013, at 8:17 AM, "David Goodell (dgoodell)" wrote: > On Jul 18, 2013, at 9:53 AM, Ralph Castain wrote: > >> On Jul 18, 2013, at 7:05 AM, David Goodell (dgoodell) >> wrote: >> >>> On Jul 18, 2013, at 8:06 AM, Ralph

Re: [OMPI devel] ompi_info

On Jul 18, 2013, at 9:53 AM, Ralph Castain wrote: > On Jul 18, 2013, at 7:05 AM, David Goodell (dgoodell) > wrote: > >> On Jul 18, 2013, at 8:06 AM, Ralph Castain wrote: >> >>> That's a good point, and a bad behavior. IIRC, it

[OMPI devel] KNEM + user-space hybrid for sm BTL

Hello, Could someone, who is more familiar with the architecture of the sm BTL, comment on the technical feasibility of the following: is it possible to easily extend the BTL (i.e. without having to rewrite it completely from scratch) so as to be able to perform transfers using both KNEM (or

Re: [OMPI devel] ompi_info

On Jul 18, 2013, at 7:05 AM, David Goodell (dgoodell) wrote: > On Jul 18, 2013, at 8:06 AM, Ralph Castain wrote: > >> That's a good point, and a bad behavior. IIRC, it results from the MPI >> Forum's adoption of the MPI-T requirement that stipulates we

Re: [OMPI devel] ompi_info

On Jul 18, 2013, at 15:06 , Ralph Castain wrote: I think ompi_info has always shown all the variables despite what you have the selection variable set (at least in some cases). We now just display everything in all cases. An additional benefit to the updated

Re: [OMPI devel] ompi_info

On Jul 18, 2013, at 8:06 AM, Ralph Castain wrote: > That's a good point, and a bad behavior. IIRC, it results from the MPI > Forum's adoption of the MPI-T requirement that stipulates we must allow > access to all control and performance variables at startup so they can be >

Re: [hwloc-devel] upcoming cleaning of headers and doc sections

Brice Goglin, le Thu 18 Jul 2013 14:10:28 +0200, a écrit : > * only put the prototypes in hwloc.h and keep the inline code somewhere else > * if some sections are obviously less important, keep these out of > hwloc.h (just like the ones in hwloc/helper.h currently) I'd say these two. Samuel

Re: [OMPI devel] ompi_info

On Jul 17, 2013, at 20:15 , "Jeff Squyres (jsquyres)" wrote: > On Jul 17, 2013, at 12:16 PM, Nathan Hjelm wrote: > >> As Ralph suggested you need to pass the --level or -l option to see all the >> variables. --level 9 will print everything. If you think

[hwloc-devel] upcoming cleaning of headers and doc sections

FYI, I recently got a lot of feedback about our function lists and documentation sections. http://www.open-mpi.org/projects/hwloc/doc/v1.7.1/modules.php Several of these sections have confusing names, so I am going to reorganize all this. Non-inline functions were initially considered the