> I think that you are stuck in a terminology problem. As I understand it,
> most everybody talks about "swapping" (paging out an entire process to
> the disk, and bring in another full process) when they really mean
> "paging" (moving one or more pages to or from swap-space).
When I said swapping I meant moving an entire process to disk
and then bring in another, and not paging.

> In tight memory situations the paging algorithm will fail, because a
> ...
That's exactly what's happening.  I want NetBSD to start swapping
because it is behaving very poorly when it's paging.

Some more information about my test:
The test is running a compiler that requires about 10M of
memory.  The machine has 16M of physical memory.  You then
get these figures:
	 152.70u  31.84s    3:33.70 86.3%
If you instead run two of these at the same time you get
	 156.61u  61.52s 1:31:23.59  3.9%
	 156.93u  62.51s 1:32:19.86  3.9%

This is 25 times slower!!!  With optimal scheduling (first
one compilation, then the next) it would be 2 times slower.
But the OS insists on trying to keep both processes in memory
all the time which means that they are both memory starved
and page like crazy - making very little progress.

What is needed is the bold SWAP decision to move one of them out
to disk and let it stay there for a while.  *BSD used to be able
to do this pretty well, but that code seems to be #ifdef'ed away
in NetBSD.

The same figures for SunOS 4.1.3:
1:	 654.85u 114.68s   14:15.93 89.9%
2:	 719.68u 324.81s 1:16:09.99 22.8%
	 718.91u 325.39s 1:16:10.37 22.8%
This is a slower machine, but you can see that the factor is
only 5.  Not good, but much better.

If I get some spare time I might try enabling the swap code
in the kernel.

	-- Lennart