swap space

Chris Lewis clewis at ferret.ocunix.on.ca
Fri Jun 14 17:19:18 AEST 1991

In article <1991Jun13.065207.10089 at ucunix.san.uc.edu> adams at ucunix.san.uc.edu (J. Adams - SunOS Wizard) writes:
>In article <1991Jun11.030216.6155 at ceilidh.beartrack.com> dnichols at ceilidh.beartrack.com (DoN Nichols) writes:
>>In article <1991Jun9.170520.4087 at yenta.alb.nm.us> dt at yenta.alb.nm.us (David B. Thomas) writes:
>>	It looks for the special device file "/dev/swap".  Here, we see that
>>it is the same major and minor device numbers as /dev/fp001, and probably
>>should be linked, but isn't on this system.  If you do so, you should use
>>the permissions and ownership of the "swap" listing.

/dev/swap is *usually* just a convenient invariant name for ps and
other user-level tools that rummage around inside other processes's address space
to find the swap area.  Most UNIX kernels have swapdev hardcoded as a major/minor
pair in the binary.  These machines usually need to have the kernel relinked
to change swapdev.  "/dev/swap" is just a convenience so you don't have to
recompile the user-level processes like ps.  There are a few machines that
postpone swap device assignment to somewhere early during the boot phase and use
special system calls to do it.  But I don't think the 3b1 is one of those.
If you simply rename /dev/swap the kernel won't notice, but ps will, and
will rummage thru the "wrong" swap area.

On SVR3 on a 3b2 or 386, on the other hand, you link in the initial swapdev,
and you can append swap devices during multiuser so that you can have
your paging area spread across physical devices.

>There also seems to be some confusion concerning swapping.  Swapping and
>paging are the same process.  Only the amount of data transferred is

Not quite.  When you have a pure swapping system (eg: V7, early System V's,
V32), the process gets completely swapped out, and the process can't be
restarted until the whole process gets swapped in.  These machines
either cannot support demand load (eg: 68000's), or didn't want to bother...
On dual systems, they frequently swap out, and then page fault back in.

>The kernel resorts to swapping entire processes as a last
>resort when the memory is nearly full and it needs a bigger chunk of
>memory than it can get from swapping unused pages.  All of this memory
>must still reside within the virtual address space of the system.  Thus,
>the notion of swapping to one device and paging to another is

In systems capable of both swapping and paging (eg: BSD 4.x), the algorithms
for deciding which to do is rather system dependent.  One common reason
for swapping on "simpler" machines is when you have to do raw I/O with
buffers that span page boundaries, and you have to do a page shuffle to
get the pages contiguous.

>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

(alternate blocks and filesystem overhead on a swap partition?  It's
not a file system!)

>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 may be true of a specific paging algorithm, but I think you may
be getting a bit confused yourself.  Are you speaking in general terms,
or with a specific paging implementation in mind?  In general, there's no
particular reason that a paged out process be part of the address space of
anything - the kernel only needs to associate a given page fault from a specific
process with the set of page descriptors describing that process from
which to find a disk address.  In many cases, the swap space need only be
constrained by the size of the integer used for disk addresses, and
the virtual space of the kernel is "just" the physical memory.  There
a several examples of systems with virtual memory and paging where the
total of process virtual address spaces considerably exceed the number of
address lines that the processor has (eg: MVS and VM especially with
pre-XA 24 bit physical addresses).

I have this awful feeling that the total virtual address space limit on
a 3b1 is simply because they fixed the size of the page table pool or
some other reason.  The 4mb physical limit is a different story.
Chris Lewis, Phone: (613) 832-0541, Domain: clewis at ferret.ocunix.on.ca
UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List:
ferret-request at eci386; Psroff (not Adobe Transcript) enquiries:
psroff-request at eci386 or Canada 416-832-0541.  Psroff 3.0 in c.s.u soon!

More information about the Comp.sys.3b1 mailing list