httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j..@helios.de (Jens-Uwe Mager)
Subject Re: Question: mmap und shared mem
Date Fri, 21 Aug 1998 12:09:17 GMT

>When I use shmget/shmat/shmdt/shmctl all my processes can read and write in
>parallel as long as I syncronize them for writing with a mutex. But when I use
>mmap (should be independed of the anonymous mmap or the /dev/zero variant) the
>things are more complicated: When processes mmap a file they can read and
>write (again with a mutex for writing, of course) while all immediately see
>the change as with shmget & Co, right? But when using mmap to read a file
>which is written via write() by another process the mmap'ed version doesn't
>change, right? Because this seems the main drawback of mod_mmap_static.c IMHO,
>BTW.

In theory there should be no difference in behaviour if you use shmat
style shared memory or mmap style shared memory. If you have a machine
with a unified VM/buffer cache, even a write should be immediatly
reflected in the mmap'ed shared area. I know that Linux did (does?) not
have a fully working mmap and this could happen. But for example on
System V.4 based machines with the fully implemented mmap this does not
happen, as well as other Unix variants like AIX or HPUX >= 10.

But there may be other problems with mmap versus shmat, namely virtual
address aliasing. Some processor architectures (PA-RISC, POWER/PowerPC)
have a MMU that uses a hash function to map virtual to physical
addresses. This has the problem that you can not have two virtual
addresses map to the same physical page easily as you can with the tree
structured page tables used for example on x86 or SPARC.

On HPUX with PA-RISC for example mmap will return an error if you
attempt to map a segment of a file that is already mapped in a
different process and the virtual address the other process used is not
free in your process.  HPUX actually strives to avoid that problem by
putting all mappings in one quadrant (aka segment) of the address space
and by allocating unique addresses across all processes.

AIX with PowerPC also has that problem, but they do not return an error
on performing the mmap, but instead steal the mappings from the other
process and use a kind of ping-pong to allocate the unique mapping
between the processes. The problem here is that you incurr a page fault
with MMU reload each time a process switch occurs and you reference the
mmap'ed segment.

Both HPUX and AIX do put shmat style shared segments in a special part
of their address space and insure that virtual addresses can not
overlap. AIX even provides a special variant of shmat that accepts a
file descriptor as the shared memory segment ID to perform a mmap for a
file, but using the special address space allocation of shmat.

For portable use of shared memory I currently use the following
homegrown guidelines:

	* For just shared memory to communicate between processes use
	  shmat and friends if available or use mmap if it really works
	  like on Solaris. Alternatively use things like MACH
	  vm_allocate/vm_inherit to get real shared memory.

	* To speed up file reading by avoiding the kernel/user copy use
	  mmap for large files, but be prepared to fall back to read if
	  the mmap fails for some obscure reason.

	* Use normal write for file updates and do not mix it with
	  mmap'ed reading of the same file.

Jens-Uwe Mager

HELIOS Software GmbH
Steinriede 3
30827 Garbsen
Germany

Phone:		+49 5131 709320
FAX:		+49 5131 709325
Internet:	jum@helios.de

Mime
View raw message