On Aug 10, 2009, at 11:47 AM, Lenny Verkhovsky wrote:
I also have another question
$ompi_info -aa|grep mpool |grep sm
MCA coll: parameter "coll_sm_mpool" (current value: "sm", data
source: default value)
MCA mpool: parameter "mpool_sm_allocator" (current value:
"bucket", data source: def
On Aug 10, 2009, at 10:11 AM, Lenny Verkhovsky wrote:
Don't these allocations of bshe->smbhe_keys require some kind of
memory translation from 1 proc's memory space to another ( in
bootstrap_init function /ompi/mca/coll/sm/coll_sm_module.c )
If local rank0 allocates ( get attached to ) memor
I also have another question
$ompi_info -aa|grep mpool |grep sm
MCA coll: parameter "coll_sm_mpool" (current value: "sm", data source:
default value)
MCA mpool: parameter "mpool_sm_allocator" (current value: "bucket", data
source: default value)
what do these names mean, and dont they have to
Don't these allocations of bshe->smbhe_keys require some kind of memory
translation from 1 proc's memory space to another ( in bootstrap_init
function /ompi/mca/coll/sm/coll_sm_module.c )
If local rank0 allocates ( get attached to ) memory, others can't read it
without proper tranlsation.
Lenny
O
We saw these seqv too with and without setting sm btl .
On Fri, Aug 7, 2009 at 10:51 AM, Ralph Castain wrote:
>
>
> On Thu, Aug 6, 2009 at 3:18 PM, Jeff Squyres wrote:
>
>> Ok, with Terry's help, I found a segv in the coll sm. If you run without
>> the sm btl, there's an obvious bad parameter
On Thu, Aug 6, 2009 at 3:18 PM, Jeff Squyres wrote:
> Ok, with Terry's help, I found a segv in the coll sm. If you run without
> the sm btl, there's an obvious bad parameter that we're passing that results
> in a segv.
>
> LANL -- can you confirm / deny that these are the segv's that you were
>
On Aug 6, 2009, at 5:18 PM, Jeff Squyres (jsquyres) wrote:
I'm therefore going to change the mpool string names that btl/sm and
coll/sm are looking for so that they get unique sm mpool modules.
(another case of "I knew what I meant, but that's not what I typed")
I'm going to [try to] change
Ok, with Terry's help, I found a segv in the coll sm. If you run
without the sm btl, there's an obvious bad parameter that we're
passing that results in a segv.
LANL -- can you confirm / deny that these are the segv's that you were
seeing?
While fixing this, I noticed that the sm btl and
