This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
On Mar 31, 2009, at 11:00 AM, Jeff Squyres wrote:
> On Mar 31, 2009, at 3:45 AM, Sylvain Jeaugey wrote:
>> Sorry to continue off-topic but going to System V shm would be for me
>> like going back in the past.
>> System V shared memory used to be the main way to do shared memory on
>> MPICH and from my (little) experience, this was truly painful :
>> - Cleanup issues : does shmctl(IPC_RMID) solve _all_ cases ? (even
>> -9 ?)
>> - Naming issues : shm segments identified as 32 bits key potentially
>> causing conflicts between applications or layers of the same
>> on one node
>> - Space issues : the total shm size on a system is bound to
>> /proc/sys/kernel/shmmax, needing admin configuration and causing
>> between MPI applications running on the same node
> Indeed. The one saving grace here is that the cleanup issues
> apparently can be solved on Linux with a special flag that indicates
> "automatically remove this shmem when all processes attaching to it
> have died." That was really the impetus for [re-]investigating sysv
> shm. I, too, remember the sysv pain because we used it in LAM, too...
What about the other issues? I remember those being a PITA about 15
to 20 years ago, but obviously a lot could have improved in the