>	* Because there are no free pages left,  scanning  is
>	  activated, perhaps from vm_pageout()?.  This scanning forces
>	  cleaning of at least  min_free pages (per second).  These
>	  pages are put in the laundry (asynchronous writeback) but
>	  *are not* put on the free list.

Although it is probably way too late at night to try to reason things out by
simple code inspection, I thought I'd try anyway ;-).  One thing that struck
me in reading the code is that if the VM Object to which a page is attached
is locked when the pager examines a cleaned page, it won't be freed.  I wonder
if what's happening is that the memory pig that sent the system into thrashing
isn't ending up holding its objects busy thus keeping its own pages off the
free list.  This is an inconsistent explanation, though, since you'd expect it
to be able to deadlock the system eventually, not just make it dog slow.

However, it might be instructive for someone to add counters to vm_pageout.c
to count the number of vm_object_lock_try() disappointments.

> Charles, is it at all possible that the TAILQ changes  to vm_pageout.c
> are causing a pathological ordering of the active list?

I don't think so, people have been complaining about this pathology since
well before the TAILQ changes, if I recall.