Summary: How swap works

From: Brett Chapman x5156 (
Date: Wed Apr 18 1990 - 12:19:49 CDT

        Well, I had a few responses on how swap works, and a ton of requests
for a summary. Here are the explanations I recieved. Thanks to all.

From: crdgw1!!yih%atom@gemed (Benny Yih)

        The way the mem hierarchy runs is: everything in cache is in dram,
everything in dram (reg mem) is in swap. Not real efficient, but easier to do
when shuffling pages around.

        cheers, benny
From: crdgw1!helios.TN.CORNELL.EDU!

          Essentially, the virtual memory space (the swap space) under
        Unix is mapped into physical memory as needed. Whenever a
        program is started, it is copied into the swap space (and
        physical memory) as needed.

          So, the basic effect is that the physical memory is a fast
        "window" into various parts of the system's virtual memory space.
        The size of the virtual memory (how much stuff you can allocate)
        is equal to the size of the swap space (less some overhead). The
        size of physical memory dictates how efficiently one can access
        different parts of the virtual memory. More physical memory means
        less swapping things on and off the disk which means faster

          Because the physical memory is a "window" into the virtual
        memory, you need to have the virtual memory equal to or
        greater than the physical memory size.

          For more information on the basics of how a virtual memory
        machine works, see Operating System Concepts by Tannenbaum. I
        *think* this is the title/author, it's been a while. I have
        the book (but not right here), so if you wish I can get you
        all the appropriate info.

                                -- Lewis R. Jansen, LASSP/LNS Systems Admin
From: crdgw1!!stpeters@gemed (Dick St.Peters)

I believe that unix tries to anticipate that active processes might
grow and swaps out idle processes to make room. The idea is that
active processes should not have to wait for inactive ones, which
makes sense to me. It's a design decision; things can be done

I think the requirement that there be at least as much swap as memory
has to do with virtual memory efficiency. Paging needs to be as fast
and efficient as possible; it can't afford the overhead of worrying
about whether a memory page has a corresponding swap space page, so
the swap-to-ram mapping has to be pre-assigned before the paging code
ever deals with it. Again, this is a design decision. However,
trying to do swap space allocation for paging on an as-needed basis
gets real sticky when the system memory+swap usage nears capacity.

Dick St.Peters, GE Corporate R&D, Schenectady, NY	uunet!!stpeters

------------------------------------------------------------------------------ From: crdgw1!!

I do not know the definitive answer, but I have a theory of why SunOS needs at least as much swap as physical memory.

If you assume that swap space is at least as big as memory, then you could also set up the OS so that all pages in memory are also automatically written to the swap device.

SunOS has shared code and shared dynamic libraries, so there will be some pages in memory which are read-only and never, ever changed by any user program. If the system needs to free some memory the best candidate is an unused (i.e. not recently referenced), shared code page. These pages are unmodified, already on the swap device, and so do not have to be paged out.

Freeing and using unreferenced, shared code pages first can boost swapping performance, since only one page-in needs to be done, not a page-out and page-in.

Mike Berkley, University of Waterloo PAMI Lab {utai,uunet}!watmath!watnow!jmberkey

PS - I hope I've explained this correctly; it's difficult to explain it concisely. :-)

------------------------------------------------------------------------------ From: Russell Brand <crdgw1!!wuthel!brand@gemed>

Your sumary is correct. The system requires backing memory (swap disk space) for the entire virtual address space and hence you can't have more vm than you have disk.

If you take a system with 4 meg of real memory and 4 meg of vm, it WILL actually touch disk! If you are running 4.0 you can make additional swap space on the fly as a large file can be used as extra swap area. On older SUNOS you need to make bigger (or great number of) swap partitions.


------------------------------------------------------------------------------ From: crdgw1!!

Swap space is allocated when you first allocate the page in memory. It's true that pages first go into physical memory and get swapped out only when they overflow. However the address that the page is going to occupy on swap space is assigned when it is first created. This guarantees that once a page gets created, there's going to be room for it in swap space. TOPS-20 used the strategy you expected: an address in swap space wasn't allocated until it came time to swap out a page. The problem with this is that it led to programs bombing in the middle. A big lisp job would churn for hours, and then when the OS wanted to swap it out, swap space would turn out to be full. So at that point it killed the program. This is very wasteful, since you lose the hours of computing you've already done. Under Unix, if there's going to be a failure due to swap space full, you see it when your program first starts or when it tries to allocate more memory. Once a program is running with the amount of memory it needs, it has reserved swap space and you are guaranteed that it will continue to be able to run.

------------------------------------------------------------------------------ From: Steve Ackerman <crdgw1!RELAY.CS.NET!>

Basically, when a process is started, swap space is allocated for it. Hence, you have to have at least as much swap space as memory to use all of physical memory. There are some complications (sbrk, shared text, etc.). I suggest reading the Design and Implementation of 4.3 Bsd.

------------------------------------------------------------------------------ From: crdgw1!uunet.UU.NET!ksr!dgg@gemed (David G. Grubbs)

Please read up on "Virtual memory", a current topic of conversation among the most junior of programmers for a quarter century.

The simple answer is this: [For argument's sake, let us ignore the various "sharing" tricks such as BSD shared "text" and SysV "shared memory".]

The memory a process uses is independent of physical memory. "Process Virtual Memory" (the memory a single process uses) is a hunk of "secondary storage" called "swap space" (or "backing store" in England). For every page of every process, there is a page of disk space to "back it up."

Because you can touch the memory chips, "physical memory" seems fundamental, but that is an illusion. Physical memory is independent of "process memory" and can be thought of as a "cache" of most recently used pages.

Old SysV systems and ancient operating systems like S/360 used something called "Multitasking", which used physical memory in the way you describe. It is possible that if memory sizes, speeds and prices improve much faster than disk (and other secondary storage) the old physical model might again prevail. But I doubt it.

------------------------------------------------------------------------------ From: Steve Chappelow <crdgw1!RELAY.CS.NET!>

4.3BSD pre-allocats swap space 1-to-1 for virtual memory space to avoid the embarassing situation of deadlock. This can happen when there is no (logically) contiguous chunk of swap space big enough to hold any of the processes currently sleeping in memory, and there are newly runnable processes swapped out that can't be reloaded because there's not enough memory to map them. To avoid this BSD makes sure there is a place for all virtual address space on the swap device. Samuel Leffler et. al. and Maurice Bach are books that detail deadlock, pre-allocation, and all thing that manipulate the swap/virtual space.

We had the unfortunate situation of having more physical RAM than swap space at one time, but a line like /export/swap/localhost swap swap rw 0 0 allowed us to swap to a file til we repartitioned.

Steve Chappelow Systems Programmer EMBA Computer Facility ( || uunet!uvm-gen!swc) (802)656-2926

END OF MAIL MESSAGE ---------------------------------------------------------

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:57 CDT