shared memory

[Conor P. Cahill]

In article <21223 at mimsy.umd.edu>, chris at mimsy.umd.edu (Chris Torek) writes:
> 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....

SHMMAX is the maximum size of a single segment, not the total amount
of shared memory system wide, so raising it should not matter.

I don't believe that shared memory is reserverd at boot time because
I worked with a project that implemented shared libraries using shared 
memory segments and we maxed out all shared memory configuration 
options without it having a detrimental effect on memory available in
the system.  Another issue is that the pagability of shared memory is
controlled by a shmctl() call to lock/unlock a segment in memory.

In a quick test, I am able to create 15 meg of shared memory segments
on a system that has only 12 meg of memory, so there cannot be a boot
time reservation of the memory for shared memory. (At least this is
so under System V/386 Rel 3.2.  I believe this is true for most
implementations).
-- 
+-----------------------------------------------------------------------+
| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
+-----------------------------------------------------------------------+