swap space

[Peter H. Schmidt]

In [a bunch of] article[s] [several people reply to Don Nichols' post about
swapping, etc.]:

Just a couple of points I wanted to clarify:

o The 3b1 imposes a *per process* limit of 4M of *virtual memory*.  Thus, every
process can malloc up to 4M for itself, as long as there is enough physical
memory to back it up.

o Without some clever hardware hacks (involving installing a memory board in
a way which fools the 3b1 about what slot it is in), there is a 3.5M
RAM limit, i.e. you can't have more than 3.5M of RAM.

o Physical memory = RAM + sizeof(swap partition) - sizeof(kernel)


Therefore, with a 2M mother board, no memory cards, a 4M default (5000 ~=
4 * 1024 * 1k) swap partition, and a ~300k kernel:

  Physical memory = 2M + 4M -.3M = 5.7M

Thus, all your daemons, your shell and everything else have up to 5.7M to
split between them.  If, like me, you tend to run two GNU-Emacses w/tons
of elisp loaded, increasing the swap partition to 8M, say, can be a big help,
eliminating the annoying "doing vfork: not enough space" message.  This I know
from experience :-)

The absolute maximu physical memory a hacked-to-rediculousness 3b1 could have
would be:
	PM = 4M + 180M -.3M = 183.7M
...with memory board hack, 3.51, WD2010, one of those big 180M disks, and a 0k
file partition (/dev/fp002).  Of course, it wouldn't be a very *useful*
machine configured this way...
 
As to the issue of "swapping off one disk and paging off the other", I can
state that it is perfectly possible (leaving aside the point about the
distinction between paging and swapping - I mean here that your VM backing
stores can perfectly well reside on multiple disk partitions).  For example,
BBN's nX derivative of MACH implements the pager as a process outside of the
kernel, and it pages off of whatever mounted device has the most free space
(it just grabs blocks off the free list).  Thus, paging can often be spread
among several disks or partitions, and it works fine, because the pager has a
nice little table telling it where to find the page that has virtual address
0xDEADBEEF when your program tries to touch it.  (That's a *little*
oversimplified ;-)


So, to review: each process has a hope of grabbing up to 4M, but can only get
as much of that 4M as there is physical memory left free (which may well be
all of the 4M).  OK?

--Peter

--
Peter H. Schmidt	| ...mit-eddie!winter!pschmidt
3 Colonial Village, #10	| winter!pschmidt at mit-eddie.mit.edu
Arlington, MA  02174	| -- Speaking for myself.