I think if we re-frame this, we end up witn a non-issue.

Firstly, the notion of "swap" is antiquated and has no purpose in an OS on
the verge of the 21st century.

The correct way to do this, IMHO, is to use unallocated filesystem space
as swap space.

The bit vectors that hold allocation status are in memory (as well as on
disk).  When some disk space is needed for "swap" then only the in-memory
allocation status vector is changed to reflect that some piece of the
disk is "used" and can't be allocated by real files.

Since this is in-memory, it cleanly survives a crash, because on disk these
parts used as "swap" are not shown as allocated.

This method has the further advantage that (on a disk that's not nearly
full) you can often locate what I will call this "Dynamic Swap Space" near
the data files that are being used, and therefore, minimize total disk I/O
time compared with a fixed swap allocation scheme.

It -is- true, as in any buffer stacking situation, some run-amok process
could request infinite DynaSwap space; in that case, pointing the kill -9
at the next process that requests another page seems like a reasonable
strategy.

Lastly, I think it's totally bogus on a VM system if I can't have an array
that uses up the whole disk if I want, so the programmer has this abstraction
of a Very Large Memory.  In braindead architectures like the i386, I'm
probably limited to 4 GB, but in reasonable architectures, I don't see why
there needs to be any other limit than available disk space.

-Mike Cheponis



On Wed, 12 May 1999, Chuck Silvers wrote:

> "Erik E. Fair" writes:
> > As for the swap question, it really devolves down to the resource
> > accounting issue, which you get into whether you have swap or not: how well
> > does NetBSD deal when there is no more RAM (or RAM+swap)?
> > 
> > I know that the MACH VM had this notion of "lazy allocation" which allowed
> > for large, sparse address spaces, but lost terribly if a resource crunch
> > hit. I also know that we've been tightening up on the resource accounting
> > with UVM, but it's not clear to me what we do for the "sorry, we're all
> > out" case right now.
> > 
> > I'm all in favor of the suggestion that was made the last time this came
> > up: a VM with two behavior modes: strict accounting, and lazy accounting,
> > where the strict model doesn't allow anyone to allocate more RAM than you
> > have, and the lazy model allows you to ask for whatever you want, just so
> > long as you don't use it all. This sort of thing probably has to be a
> > system-wide policy decision, though there was a suggestion that it could be
> > per-process, provided that a process which requested lazy allocation would
> > be the first to die in a crunch.
> 
> Mach VM would invariably hang if something allocated all the RAM+swap
> in the system and still wanted more.  UVM in 1.4 deals with this by
> killing anyone who wants to allocate another swap-backed page when
> RAM+swap is full, on the theory that the process that allocates the
> next page is the one most likely to be causing the shortage.
> 
> as for eager vs. lazy swap allocation, I agree that making it globally
> selectable is a good plan.  we should probably have the system come up
> in eager mode, with a one-way sysctl to switch to lazy mode.  this is
> not very near the top of my todo list (or chuck c's either, I think),
> so it'll be a long time in coming unless someone else steps up to do the
> work.  hint, hint :-)
> 
> -Chuck
>