On Thu, 10 Jun 2010, Jeff Squyres wrote:
Sam -- if the shmat stuff fails because the limits are too low, it'll
(silently) fall back to the mmap module, right?
From my experience, it completely disabled the sm component. Having a nice
fallback would be indeed a very Good thing.
Sylvain
On Jun 10, 2010, at 4:57 AM, Sylvain Jeaugey wrote:
> > As for why mmap is slower. When the file is on a real (not tmpfs or other
> > ramdisk) I am 95% certain that this is an artifact of the Linux
> > swapper/pager
> > behavior which is thinking it is being smart by "swapping ahead". Even
On Jun 10, 2010, at 4:43 AM, Paul H. Hargrove wrote:
> One should not ignore the option of POSIX shared memory: shm_open() and
> shm_unlink(). When present this mechanism usually does not suffer from
> the small (eg 32MB) limits of SysV, and uses a "filename" (in an
> abstract namespace) which
On Thu, 10 Jun 2010, Paul H. Hargrove wrote:
One should not ignore the option of POSIX shared memory: shm_open() and
shm_unlink(). When present this mechanism usually does not suffer from
the small (eg 32MB) limits of SysV, and uses a "filename" (in an
abstract namespace) which can portably
On Wed, 9 Jun 2010, Jeff Squyres wrote:
On Jun 9, 2010, at 3:26 PM, Samuel K. Gutierrez wrote:
System V shared memory cleanup is a concern only if a process dies in
between shmat and shmctl IPC_RMID. Shared memory segment cleanup
should happen automagically in most cases, including abnormal
