swap space

[Tom Tkacik CS/50]

In article <1991Jun13.170111.28789 at athena.mit.edu>,
pschmidt at athena.mit.edu (Peter H. Schmidt) writes:
|> 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.

Whoa there!  That's not right.  Just because there is a 4Mb virtual limit
does not mean that you can malloc 4Mb.  The number floating around is 2.5Mb.
That is how much of the 4Mb you have access to.  The rest is the kernal and
shared libraries, which for some reason apparently take up 1.5Mb.

|> 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.

Wrong again.  You can have 4Mb of physical memory in a 3b1.  No need for
hardware hacks either; unless you call installing a 2Mb memory card
a hardware hack.  I speak from experience when I say that my UnixPC has
4Mb of physical memory in it.

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

I have never heard of this definition, but it's no worse than any other.

|> 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

Be careful with your numbers.  I believe that the kernel takes up
more than .3Mb, you have a bunch of buffers and things in there too.

I have never gotten a reply on a question I have.  If you have 4Mb RAM, and
7Mb swap space, can you run 11Mb worth of programs, or are you limited to
how much swap space you have?  I'm not sure that they add up that way.

|> 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 :-)

I would be very reluctant to try to do the math you just did.
There are other variables you need to take into account, like how many kernel
buffers are there.
Increasing swap space is a good way to allow running two or three
gcc compiles and emacs at the same time (I have a 10Mb swap partition at home);
just don't try to be so exact, it's not that important.

(A quick note.  The 3b1 does not have vfork.  That is a Berkeleyism.)

|> 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...

You neglect the fact that you could install a second hard disk.

|> 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 ;-)

I think that this discussion was pertaining to the 3b1.  You can only
have a single swap partition.  Other machines can, and do, implement
things differently.

|> 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?

You've got the right idea.  Some of the details are questionable.

--
Tom Tkacik
GM Research Labs
tkacik at hobbes.cs.gmr.com
tkacik at kyzyl.mi.org