Just to clarify some obvious misconception regarding paging/swapping in
NetBSD or any (unmodified) 4.4BSD VM system.

Swapping in the 4.4BSD derived system is quite uninteresting as it merely does
nothing to help the VM system. The only thing that swapping does to a process
is make its user struct (including the kernel stack) pageable. Since the now
pageable pages are placed at the end of the active queue, it lasts quite long
till they are actually paged out. My guess is, that even under heavy load most
processes will be swapped in before these pages are actually paged out. This
means that swapping has only some minor effect due to swapping some long
sleeping processes.

One other misconception seems to be that pages are moved in/out by the
paging system in chunks. There is some code that would do this for the
pageout, but it is disabled via #ifdef CLUSTERED_PAGEOUT. Pagein is always
one page at a time.

> I'm also curious to know whether the swapper moves
> shared pages (particularly text pages) to and from swap
> when invoked.  I'd hope not, but it's worth a look, since
> some of the I/O-time vs CPU time tradeoffs in the Berkeley
> VM are interesting.

The pager moves pages from the active to the inactive queue, and from there
to the free queue, independent of the object and the references to these
pages. Only if they are activated while being on the inactive queue are they
left in memory.

Note that text pages are not normally moved to the swap space, as they will
be paged from the original executable.

> | IMNSO, a VM system should keep a pool of free pageframes at all times,
> | to satisfy pagefaults without having to first page something else out.

Actually, the VM system does keep a pool of free pageframes at all times, at
least it tries to. See above.

> The problem is that when there is a large short-term demand
> for memory, one has a couple of obvious options:
> 
> 	-- spend lots of CPU in the pager, accelerating the
> 	   clock hands and getting rid of "LRU" pages
> or	-- spend much less CPU by swapping a process that
> 	   has lots of memory in use and which hasn't run
> 	   very recently
> 
> The current VM does the latter.  This might even be the
> better of the two approaches on all but very crunchy CPUs
> provided that very big swap operations don't block the operation
> of other processes.

As said above, the old Berkeley VM system might have done the latter, but the
current Mach-derived VM system doesn't do anything significant when swapping
a process out.

While I'm not sure about the implications of all this for the problem at hand,
I hope it clarifies some concepts of our current VM system.
--
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800