| Actually, it looks more to me like it isn't paging aggresively enough
| to begin with.  So, when a heavy demand for memory comes all of a
| sudden, it has to work too hard to try and free up enough memory.

Well, this may be just me and my tastes, but I really don't
like the idea of unnecessary paging.

That is, I'd rather see even pages that haven't been used
in a very long time stay in physical memory until something
newer needs space which isn't there.  (Spot the LISP person...)

My fuzzy memory of the Berkeley VM design is that real LRU
was excessively expensive in terms of CPU and may have been
considered impractical or impossible in terms of space or
hardware, and so it wasn't done in 3BSD, but something
that kinda approximated LRU was.

Moreover, the odd concept of page clustering was done in 4.1 to
work around the expense of doing things on a hardware page
basis, and the swapper was resurrected to move multiple
clusters in and out of physical memory as much as possible.

Assuming my memory isn't broken, the trade-off all through 
the evolution of the VM through 4.3 was lots of possibly-
unnecessary I/O for the sake of smaller tables and less CPU,
and the later Machification didn't undo this.

In this kind of environment, one wouldn't want to do any
more unnecessary paging than what already was happening,
I guess.  

I also seem to remember that alot of the way the CLOCK
algorithm was dropped into the Berkeley VM was based
on simulations that probably don't match many current site
setups, and the point at which the system decides that
paging won't keep up with demand without spending too much
CPU walking through the loop of pages is still based on that work.

There's probably a caveat around somewhere in the BSD literature
along the lines of "swapping is too slow; memory scheduling
should be done by the pager if you value system performance".

As a simpler set of changes than my previous suggestions, one
might consider looking at the paging paramaters, and adjusting
the point (minfree) at which the swapper is invoked, or,
to take your approach, adjusting the amount of memory
the pager daemon tries to keep free at all times (desfree).

You could also tweak lotsfree, which is the point at which
the pager stops scanning through the loop of pages looking
for things to get rid of.

(I may not be remembering changes done through the VM since the old
days, and as I confessed earlier, I can't just UTSL today...)

| What is notable is that it usually takes several of these multi-second
| pauses for it to free up enough memory for everything to run again, in
| many cases.

It would be interesting to know which processes were
swapped in and out during these multi-second pauses.

	Sean.