>>That might help when you're running low on physical memory.  it
>>doesn't do jack for the fact that the system wedges when you run out
>>of RAM + swap.

>It doesn't do
>anything for the stability of the system (or, if other things are
>properly written, it shouldn't 8-),

No, it's not a fix for running out of swap + RAM.  It's a fix
for running out of RAM, which was one of the things Jukka explicitly
mentioned.  Which was what I was replying to.

Wedging solid for over 1 minute whilst the system dribbles out all
dirty pages, in a small write once per second, is (IMHO) _NOT_ just a
`performance problem'.  It makes the system unusable.  Perhaps you've
never experienced running out of RAM on a large-memory NetBSD/1.2
machine?

> and doesn't solve the problem
>i mention above (which is _not_ clearly elucidated in the message you
>quote).

No, but then I never claimed it did, and it sounded like the problem
Jukka Marin was referring to.  If it wasn't,  my apologies. :).

And, as John Dyson has pointed out repeatedly, this is just a
band-aid.  The 4.4-Lite VM system really should be replaced with
something better engineered for heavy load (i.e., environments where
paging is necessary).  This isn't particularly hard; but needs a fair
chunk of time, which nobody has yet managed to dedicate.

I had floated the idea of incorporating the OpenBSD fix for collapsing
copy-object chains.  Seems that's not a viable option as things stand.
I suggested a Gross Hack to Jason: locking enough VM objects to
release one copy object (shadow chain?)  at a time, and then,
essentially, starting again.  The performance would be atrocious, but
it should be possible to get right, and might (repeat, _might_) be
better than doing nothing.   Anyone care to comment on that?