Now in the trunk (see r23260).
Thanks everyone!
--
Samuel K. Gutierrez
Los Alamos National Laboratory
On Jun 1, 2010, at 11:08 AM, Samuel K. Gutierrez wrote:
WHAT: New System V shared memory component.
WHY: https://svn.open-mpi.org/trac/ompi/ticket/1320
WHERE:
M ompi/mca/btl/sm/btl_sm.
On Jun 2, 2010, at 11:58 AM, Samuel K. Gutierrez wrote:
Good point - I forgot about that.
--
Samuel K. Gutierrez
Los Alamos National Laboratory
On Jun 2, 2010, at 11:40 AM, Jeff Squyres wrote:
Don't forget that the RML is also used to broadcast the success/
failure of the creation of the sha
Good point - I forgot about that.
--
Samuel K. Gutierrez
Los Alamos National Laboratory
On Jun 2, 2010, at 11:40 AM, Jeff Squyres wrote:
Don't forget that the RML is also used to broadcast the success/
failure of the creation of the shared memory segment.
If the RML goes away, be sure that y
Don't forget that the RML is also used to broadcast the success/failure of the
creation of the shared memory segment.
If the RML goes away, be sure that you can still determine that without hanging.
Personally, I still don't see the problem with using the RML stuff...
On Jun 2, 2010, at 1:07 P
Hi George,
That may work - I'll try it.
Thanks!
--
Samuel K. Gutierrez
Los Alamos National Laboratory
On Jun 2, 2010, at 10:59 AM, George Bosilca wrote:
How about ftok ? The init function takes a file_name as argument,
and this file name is unique per instance of the shared memory
region
How about ftok ? The init function takes a file_name as argument, and this file
name is unique per instance of the shared memory region we want to create. We
can use this file name with ftok to create a unique key_t that can be used by
shmget to retrieve the shared memory identifier.
george.
On Jun 2, 2010, at 8:49 AM, Jeff Squyres wrote:
On Jun 2, 2010, at 10:44 AM, George Bosilca wrote:
Not sure what you mean here. common/sm may create new shmem
segments at any time (e.g., during coll sm). The RML message
exchange is to ensure that only 1 process creates and initializes
t
On Jun 2, 2010, at 10:44 AM, George Bosilca wrote:
> > Not sure what you mean here. common/sm may create new shmem segments at
> > any time (e.g., during coll sm). The RML message exchange is to ensure
> > that only 1 process creates and initializes the segment and then all the
> > others jus
On Jun 2, 2010, at 09:28 , Jeff Squyres wrote:
> On Jun 2, 2010, at 5:38 AM, George Bosilca wrote:
>
>> I think adding support for sysv shared memory is a good thing. However, I
>> have some strong objections over the implementation in the hg tree. Here are
>> 2 of the major ones:
>>
>> 1) th
On Jun 2, 2010, at 7:28 AM, Jeff Squyres wrote:
On Jun 2, 2010, at 5:38 AM, George Bosilca wrote:
I think adding support for sysv shared memory is a good thing.
However, I have some strong objections over the implementation in
the hg tree. Here are 2 of the major ones:
1) the sysv shared
On Jun 2, 2010, at 5:38 AM, George Bosilca wrote:
> I think adding support for sysv shared memory is a good thing. However, I
> have some strong objections over the implementation in the hg tree. Here are
> 2 of the major ones:
>
> 1) the sysv shared memory creation is __atomic__ based on the f
I think adding support for sysv shared memory is a good thing. However, I have
some strong objections over the implementation in the hg tree. Here are 2 of
the major ones:
1) the sysv shared memory creation is __atomic__ based on the flags used.
Therefore, all the RML messages exchange is total
Hi all,
Configure option added: --enable-sysv (default: disabled).
For sysv testing purposes, please enable.
Thanks!
--
Samuel K. Gutierrez
Los Alamos National Laboratory
On Jun 1, 2010, at 11:11 AM, Samuel K. Gutierrez wrote:
Doh!
bitbucket repository: http://bitbucket.org/samuelkgutierre
On Jun 1, 2010, at 1:35 PM, Graham, Richard L. wrote:
> Can you be a bit more explicit, please ?
Sam has sent several prior RFCs on this subject. I believe he was asking for
final testing before bringing it into the trunk.
> I do not want this on our systems, so as long as this is a compile ti
Hi Rich,
I'll add a configure-time option. This addition does not negatively
impact the performance of the current sm component.
Thanks,
--
Samuel K. Gutierrez
Los Alamos National Laboratory
On Jun 1, 2010, at 11:35 AM, Graham, Richard L. wrote:
Can you be a bit more explicit, please ?
I
Can you be a bit more explicit, please ?
I do not want this on our systems, so as long as this is a compile time
decision, and as long as this does not degrade the performance of the current
sm device, I will not object.
Rich
- Original Message -
From: devel-boun...@open-mpi.org
To: Op
Doh!
bitbucket repository: http://bitbucket.org/samuelkgutierrez/ompi_sysv_sm
Thanks,
--
Samuel K. Gutierrez
Los Alamos National Laboratory
On Jun 1, 2010, at 11:08 AM, Samuel K. Gutierrez wrote:
WHAT: New System V shared memory component.
WHY: https://svn.open-mpi.org/trac/ompi/ticket/132
17 matches
Mail list logo
