Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!ames!dftsrv!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: shared memory
Keywords: portability
Message-ID: <21223@mimsy.umd.edu>
Date: 12 Dec 89 02:38:01 GMT
References: <11383@csli.Stanford.EDU> <1989Dec12.005555.20618@virtech.uucp>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 26

In article <1989Dec12.005555.20618@virtech.uucp> cpcahil@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.)
-----
% `SysRel': a replacement for `System V Release', since the `V' and
  `Release' are all redundant.  Thus, the question is not `is your
  system a System V style system' but rather `is it a SysRel 1
  system', etc.
# SysRel 4 has a much better shared memory system, now that they have
  tacitly acknowledged that not all Berkeley's proposals are bad.  (NB:
  mmap => BSD proposal, Sun implementation.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris