Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!sol.ctr.columbia.edu!ucselx!bionet!raven.alaska.edu!hayes.ims.alaska.edu!floyd
From: floyd@ims.alaska.edu (Floyd Davidson)
Newsgroups: comp.sys.3b1
Subject: Re: swap space
Message-ID: <1991Jun13.122803.25362@ims.alaska.edu>
Date: 13 Jun 91 12:28:03 GMT
References: <1991Jun9.170520.4087@yenta.alb.nm.us> <1991Jun11.030216.6155@ceilidh.beartrack.com> <1991Jun13.065207.10089@ucunix.san.uc.edu>
Organization: University of Alaska Institute of Marine Science
Lines: 123

In article <1991Jun13.065207.10089@ucunix.san.uc.edu> adams@ucunix.san.uc.edu (J. Adams - SunOS Wizard) writes:
>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
[...]
>>	You should be able to simply replace "/dev/swap" with a link to the

>
>I am strongly inclined to doubt this.  With the exception of

You are right.  The /dev/swap is there so you can do i/o to it,
not for the kernel.  

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

This could be done.  With 3.51 the object files are available
and the swap device can be changed via conf.h, but as you say,
why?  (Has anyone tried it just to see if anything unexpected
happened?  Seems like 2-3 years ago someone like Lenny or Gil
said something about this...)

>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'm no kernel expert...  My understanding is that paging and swapping
are two different ways to accomplish virtual memory...

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

Lets say you have 4Mb of swap space.  You run two programs that
each take up 1.5Mb of memory.  If you start one more there isn't
enough swap space to run it.  If you had 6Mb of swap space you
could run 3 processes that needed 1.5Mb of memory (and have some
left over...).

In practice the only way I've found to bump that limit is with
gcc, which will take all the memory it can get.  I'm using 8Mb
of swap space.  At this moment 6Mb is free.  I've seen it down
to less than 2Mb. (And at the same time the load averages were
up around 4.00 and response time was long, and it was time to
do something else for a few hours while gcc compiled two 
different versions of itself at the same time...  Not exactly
something you would normally do every day.)

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

That must be the maximum amount that can be allocated, not the
actual amount useable.  The amount you can use is the size of
the disk space allocated.

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

While there is some validity to that comparison of the memory map,
that probably isn't the reason the swap space is so small.  First
off it obviously can be changed, second they didn't see much need
(I assume) on a single user system to have more swap space than
total memory.  And remember they only had one hard disk that was
no bigger than 67Mb.  Under normal circumstances their choice of
4Mb has proven just about exactly right.

I think the gripe we have about the way it got put together is
that limit of 2.3-2.5Mb on per process virtual memory that can't
be changed.  I've got a 68020 system that also has 4Mb of real
memory, but with 8Mb of swap it can allocate 11Mb of memory to one
process (the difference is the kernel etc.).  If I had some horrible
need to do it it could be set up for 200Mb of swap and allocate
that much to one process.  Don't laugh too loud, I saw a post once
where some guy running some kind of modeling program was doing
exactly that on a Sun.

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

That fits my understanding of what is happening.  That is the
difference between swapping and paging.

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

I don't know one way or the other on this.  Does it kill the new
process or kill an old process?  I know if existing processes
ask for more memory and swap space is full it will start killing off
processes.  But I don't know what the algorithm is.

Floyd
-- 
Floyd L. Davidson   | Alascom, Inc. pays me, |UA Fairbanks Institute of Marine
floyd@ims.alaska.edu| but not for opinions.  |Science suffers me as a guest.