shared memory

[Bob Hutchison]

>From article <21223 at mimsy.umd.edu>, by chris at mimsy.umd.edu (Chris Torek):
- In article <1989Dec12.005555.20618 at virtech.uucp> cpcahil at virtech.uucp
- (Conor P. Cahill) writes:
->Modifying the SHMMAX should only require a kernel re-configuration which
->should always be an option.
- 
- As I understand it---which is not to say that it is so, for I have
- never seen the SysRel% 1, 2, or 3# code itself---the total amount of
- shared memory allowed per-system is reserved at boot time, is not
- pageable, and is effectively taken away from the rest of the system.
- For processes not using it, it is as if some of the machine's memory
- had been physically removed.
- 
- This would mitigate against raising SHMMAX arbitrarily....
- 
- (No doubt someone will follow up if my understanding is incorrect.)

[ stuff deleted ]

- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
- Domain:	chris at cs.umd.edu	Path:	uunet!mimsy!chris

I've looked at this source code for at least SVR3.x and the shared
memory creation routines allocate regions just as exec(2) allocates
regions.  Memory is not reserved at boot time; in fact it isn't even
allocated when the shared memory segment is created - its pages are
marked "demand zero" and are allocated as page faults indicate that
the pages are being referenced.  I guess this has changed in SVR4.0.

BTW, the last time I looked, shared memory was not in the parts of the
SVID where message queues and semaphores were.  It was in a section
called "optional stuff" or something like that.  Since shared memory
(and especially limits and config info) is closely tied to the memory
management architecture for the machine, it can't be made portable too
easily.

And, to quote a famous computer scientist...     8v)

- (No doubt someone will follow up if my understanding is incorrect.)

Robert Hutchison
att!lzaz!hutch