Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rphroy!hobbes.cs.gmr.com!tkacik
From: tkacik@hobbes.cs.gmr.com (Tom Tkacik CS/50)
Newsgroups: comp.sys.3b1
Subject: Re: swap space
Message-ID: <55907@rphroy.UUCP>
Date: 13 Jun 91 14:05:06 GMT
References: <1991Jun9.170520.4087@yenta.alb.nm.us> <1991Jun11.030216.6155@ceilidh.beartrack.com> <1991Jun13.065207.10089@ucunix.san.uc.edu>
Sender: news@rphroy.UUCP
Reply-To: tkacik@hobbes.cs.gmr.com (Tom Tkacik CS/50)
Organization: G.M. Research Labs, Warren, MI
Lines: 85
Nntp-Posting-Host: hobbes.cs.gmr.com

In article <1991Jun13.065207.10089@ucunix.san.uc.edu>,
adams@ucunix.san.uc.edu (J. Adams - SunOS Wizard) writes:
|> 
|> I am unsure of one other point:  As I understand it, the total (not the
|> per-process limit, which is clearly 2.5MB) virtual address space of the
|> UNIX-PC is 4 megabytes.  If this is in fact the case, increasing the
|> available swap partition beyond its default maximum of around 4.5 MB
|> (to allow for alternate blocks, filesystem overhead, etc.) cannot
|> result in any benefit.  I have never been able to get a straight answer
|> from anyone at AT&T/Convergent about this.  On most other 32-bit
|> systems, the virtual address space is 4GB (3GB for 4.x BSD on a VAX). 
|> Thus, the possible swap space is much larger than the amount of RAM
|> likely to be present.  My understanding is that Convergent decided to
|> allow just 4MB of address space for memory because they used a rather
|> wasteful allocation of available addressing to provide direct
|> addressability for almost every conceivable peripheral device/expansion
|> card.

There are two virtual memory sizes being thrown around, plus swap space.
What are these, and where do they come from?

4Mb.  This is the total virtual address space of the 3b1.  This IS
per process.  This is limited by the memory management unit of the 3b1.
Only 22 address lines are used by the MMU.  This not only made addressing
peripherals easier, it allowed for a reasonablly sized page table.
Unlike most workstations today that keep the page tables in main memory,
the 3b1 has seperate RAM for that, (making memory management simpler). 
This was the obvious thing to do back in 1984, or whenever
Convergent designed the UnixPC.  Nobody complained then.
Who would need that much virtual memory? :-)

2.5Mb.  I'm not sure why you say the per-process limit is 'clearly' 2.5Mb?
Where this number comes from is not obvious (or clear).
This is the virtual address space available for a user program,
(not process).  The kernel, shared libraries, and perhaps other sundry
stuff, is included in the virtual memory space of every process.  On the
3b1, this amounts to 1.5Mb of virtual memory.
The virtual space available for a user's program is the total virtual space
minus that used for the kernel, etc., or 2.5Mb.  Every process has
4Mb virtual memory.  You just can't get at all of it.

Swap space.  This is simply where the machine puts processes when they do not
fit into main memory.  There is no limit (ok, a very large limit) as to how
much swap space you can have.  Having more swap space will allow you to run
more (or larger) processes.

Swap space and per process virtual memory are independent of each other.

|> In any case, swapped-out processes MUST reside in the virtual address
|> space of the system, since they are not swapped _in_ as whole processes.

This is not true.  Every process must reside in the virtual address space.
You can think of the swap space as multiple virtual address spaces.
One for each running process.  Thus, more swap space, more running processes.
Each virtual address space will be
only as large as is needed by the process.  Because the kernel and
shared libraries do not change, they are not swapped out,
and are not included in the virtual address space of the swapped process.

Part of the memory management is to keep track of those multiple
address spaces in swap space.

Main memory is broken into pages, each page given to a
particular process.  The page tables are used to manage this.  Each time
a new process is scheduled to run, the page tables have to be modified to
reflect that current running process.  If all of the pages needed
are already in main memory, nothing gets swapped,
(though the page tables still need to be modified).
Only if the pages currently needed are on disk, does paging occur.
  
|>                                   In fact, a new process will not be
|> allowed to run if it cannot fit in the virtual space available.  It will
|> be killed in the memory allocation stage.

Do not confuse virtual address space with swap space.  What you are saying
is correct, but I think that you mean to say that a new process will
not be allowed to run if it cannot fit in that swap space available,
which is also correct.
This is what happens when you try to run too many large processes.

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