home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!auspex-gw!guy
- From: guy@Auspex.COM (Guy Harris)
- Newsgroups: comp.sys.sun.admin
- Subject: Re: minimum swap space for SunOS 4.1.x?
- Message-ID: <14442@auspex-gw.auspex.com>
- Date: 2 Sep 92 21:37:02 GMT
- References: <1992Sep1.211624.9653@nsisrv.gsfc.nasa.gov> <1992Sep2.205732.20742@nsisrv.gsfc.nasa.gov>
- Sender: news@auspex-gw.auspex.com
- Organization: Auspex Systems, Santa Clara
- Lines: 27
- Nntp-Posting-Host: bootme.auspex.com
-
- >"Guess it depends on what you mean by "must" be larger than
- >physical ram. If your swap ISN'T bigger than physical ram, then
- >you might as well take that excess ram and toss it - it'll never get
- >used.
- >
- >Suns pre-allocate space for text.
-
- If that means "Suns pre-allocate swap space for text", 'tain't so under
- 4.x. SunOS 4.x only pre-*reserves* swap space for regions of the
- address space that are mapped copy-on-write to a file *and* that are
- marked writable.
-
- Yes, the text of a demand-paged executable, as well as the text of
- a shared library, is mapped copy-on-write to the file. Yes, it is
- marked writable *if* the run-time loader has to do relocation on it, but
- even then, once it's done any necessary relocation, it marks it
- read-only again, which causes the reservation to be withdrawn (modulo
- bugs).
-
- BSS space and "sbrk" space also has swap space allocated to it.
-
- So, if your swap space is smaller than the physical RAM, you won't
- *necessarily* be unable to use all the physical RAM; it can still be
- used for stuff not mapped copy-on-write to files and not
- BSS/"malloc()"ed/SV shared memory (for example, for pages read
- from/written to files). You will, however, have problems if some
- application wants all of it for BSS or "malloc()"ed stuff.
-