Yo folks
As has frequently been commented upon at one time or another, the
shared memory backing file can be quite huge. There used to be a param
for controlling this size, but I can't find it in 1.3 - or at least,
the name or method for controlling file size has morphed into
something I
Ralph, is it not the mpool_sm_max_size? 512MB seems to be the default
max size per node.
devel-requ...@open-mpi.org wrote:
Message: 1
Date: Wed, 12 Nov 2008 07:21:38 -0700
From: Ralph Castain
Subject: [OMPI devel] SM backing file size
To: Open MPI Developers
Message-ID:
Content-Type: text
Date: Wed, 12 Nov 2008 07:21:38 -0700
From: Ralph Castain
Subject: [OMPI devel] SM backing file size
To: Open MPI Developers
Message-ID:
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Yo folks
As has frequently been commented upon at one time or another, the
shared memory
Ralph Castain wrote:
As has frequently been commented upon at one time or another, the
shared memory backing file can be quite huge. There used to be a
param for controlling this size, but I can't find it in 1.3 - or at
least, the name or method for controlling file size has morphed into
Hi Eugene
I too am interested - I think we need to do something about the sm
backing file situation as larger core machines are slated to become
more prevalent shortly.
I appreciate your info on the sizes and controls. One other question:
what happens when there isn't enough memory to sup
Ralph,
Are these systems running Linux? If so, the long term solution is to
finish ticket #1320:
https://svn.open-mpi.org/trac/ompi/ticket/1320
Which would eliminate the sm backing files entierly, without needing
to reduce the size of the shared memory that is used. For systems
where /tmp is a r
It's been a long time since I've looked at the sm code; Eugene has
looked at it much more in-depth recently than I have. But I'm
guessing we *haven't* checked this stuff to abort nicely in such error
conditions. We might very well succeed in the mmap but then segv
later when the memor
On Nov 14, 2008, at 7:00 AM, Tim Mattox wrote:
Ralph,
Are these systems running Linux? If so, the long term solution is to
finish ticket #1320:
https://svn.open-mpi.org/trac/ompi/ticket/1320
Which would eliminate the sm backing files entierly, without needing
to reduce the size of the shared
Until we do complete the switch, and for systems that do not support
the alternate type of shared memory (I believe it is only Linux?), I
truly believe we should do something nicer than segv.
Just to clarify: I know the segv case was done with paffinity set, and
believe both cases were done
Ok. Should be pretty easy to test/simulate to figure out what's going
on -- e.g., whether it's segv'ing in MPI_INIT or the first MPI_SEND.
On Nov 14, 2008, at 9:19 AM, Ralph Castain wrote:
Until we do complete the switch, and for systems that do not support
the alternate type of shared mem
Just a few comments:
- not sure what sort of alternative memory approach is being considered.
The current approach was selected for two reasons:
- If something like anonymous memory is being used, one can only inherit
access to the shared files, so one process needs
set up the shared me
On Nov 14, 2008, at 7:41 AM, Richard Graham wrote:
Just a few comments:
- not sure what sort of alternative memory approach is being
considered. The current approach was selected for two reasons:
- If something like anonymous memory is being used, one can only
inherit access to the s
Rich,
The forking requirement is true if you are using anonymous mmap.
It is not true when using SYSV shm segments.
I've done this over a decade ago for a non-MPI communications library.
For Linux, this is a no-brainer... I just need time to code it up to fit within
the Open MPI infrastructure. Th
Ralph Castain wrote:
I too am interested - I think we need to do something about the sm
backing file situation as larger core machines are slated to become
more prevalent shortly.
I think there is at least one piece of low-flying fruit: get rid of a
lot of the page alignments. Especially
On Nov 14, 2008, at 10:56 AM, Eugene Loh wrote:
I too am interested - I think we need to do something about the sm
backing file situation as larger core machines are slated to
become more prevalent shortly.
I think there is at least one piece of low-flying fruit: get rid of
a lot of th
Agreed.
On 11/14/08 9:56 AM, "Ralph Castain" wrote:
>
> On Nov 14, 2008, at 7:41 AM, Richard Graham wrote:
>
>> Just a few comments:
>>- not sure what sort of alternative memory approach is being considered.
>> The current approach was selected for two reasons:
>> - If something lik
Ralph Castain wrote:
I have two examples so far:
1. using a ramdisk, /tmp was set to 10MB. OMPI was run on a single
node, 2ppn, with btl=openib,sm,self. The program started, but
segfaulted on the first MPI_Send. No warnings were printed.
Interesting. So far as I can tell, the actual memo
I probably wasn't clear - see below
On Nov 14, 2008, at 6:31 PM, Eugene Loh wrote:
Ralph Castain wrote:
I have two examples so far:
1. using a ramdisk, /tmp was set to 10MB. OMPI was run on a single
node, 2ppn, with btl=openib,sm,self. The program started, but
segfaulted on the first M
Ralph Castain wrote:
I probably wasn't clear - see below
On Nov 14, 2008, at 6:31 PM, Eugene Loh wrote:
Ralph Castain wrote:
I have two examples so far:
1. using a ramdisk, /tmp was set to 10MB. OMPI was run on a single
node, 2ppn, with btl=openib,sm,self. The program started, but
se
On Sat, Nov 15, 2008 at 09:32:44AM -0800, Eugene Loh wrote:
> Ralph Castain wrote:
>
>> I probably wasn't clear - see below
>>
>> On Nov 14, 2008, at 6:31 PM, Eugene Loh wrote:
>>
>>> Ralph Castain wrote:
>>>
I have two examples so far:
1. using a ramdisk, /tmp was set to 10MB.
20 matches
Mail list logo
