Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cis.ohio-state.edu!tut.cis.ohio-state.edu!ucunix.san.uc.edu!adams
From: adams@ucunix.san.uc.edu (J. Adams - SunOS Wizard)
Newsgroups: comp.sys.3b1
Subject: Re: swap space
Message-ID: <1991Jun13.065207.10089@ucunix.san.uc.edu>
Date: 13 Jun 91 06:52:07 GMT
References: <1991Jun9.170520.4087@yenta.alb.nm.us> <1991Jun11.030216.6155@ceilidh.beartrack.com>
Organization: Univ. of Cincinnati
Lines: 81

In article <1991Jun11.030216.6155@ceilidh.beartrack.com> dnichols@ceilidh.beartrack.com (DoN Nichols) writes:
>In article <1991Jun9.170520.4087@yenta.alb.nm.us> dt@yenta.alb.nm.us (David B. Thomas) writes:
>>How does the 3b1 know where to find swap space, and can it use the "swap
>>partition" on the second hard disk?
>>
>>						little david
>
>	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.
>
>br--------  1 root    root      0,  1 Dec 30 21:42 /dev/fp001
>brw-r-----  1 sys     sys       0,  1 Dec 30 21:50 /dev/swap
>
>	You should be able to simply replace "/dev/swap" with a link to the
>selected partition on your other drive, but I know of no way to have it use
>both.  It would be nice if it did paging from one drive, and swapping to the
>other, so you could increase the space to handle emergency conditions, since
>the actual "swap" proceedure is used only under relative emergency
>conditions, with paging used for normal conditions.
>
>	You should probably wait a while to see if any reply postings from
>the "kernel cognosenti" appear with warnings before trying this, since I
>don't have access to kernel source, and am just speaking from my readings
>and general understanding.  If I gave wrong advice, I'm sure I'll hear about
>it :-)

I am strongly inclined to doubt this.  With the exception of
/dev/console (for telinit to work from a remote terminal), all the
kernel hooks are by major/minor device number, not name.  Linking
/dev/swap to some other device is unlikely to have any effect.  The
kernel will continue to page/swap on 0,1.  I suppose you might be able
to hack the kernel object files with adb to change to another
partition/disk, but I can see little benefit in doing this.  In fact,
most UNIX ports don't even have a /dev/swap entry... the swap device(s)
are invisible to the filesystem.

There also seems to be some confusion concerning swapping.  Swapping and
paging are the same process.  Only the amount of data transferred is
different.  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
impossible.

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.  Sort of like MS-DOS where you have only 640K out of 1MB (1024K)
address space addressable as RAM.

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. 
The System V swapping algorithm is not the same as the old Version 7 one
where the entire process had to fit in the RAM.  In SysVr2.1 the
swapping algorithm is essentially the same as the 4.1 BSD algorithm. 
The process must therefore fit in the VIRTUAL address space since it may
be paged in rather than swapped in as a whole entity.  Swapping in the
sense of V7 UNIX does not 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.  If you examine the kernal .o
files, you will see that the only swapping program is vmswap.c.  This
program manages/shares the same virtual address space as vmpage.c.

-- 
       Jim Adams              Department of Physiology and Biophysics
adams@ucunix.san.uc.edu     University of Cincinnati College of Medicine      
      "I like the symbol visually, plus it will confuse people." 
                                       ... Jim Morrison