Matthew Green <mrg@mame.mu.OZ.AU> wrote:

>i killed two tcsh's both using significantly less than 1meg of
>memory each (as reported by ps(1)), yet the total amount of
>swap i got back was more than 6 meg (no, no other processes
>were killed at the same time)
...
>i had previously thought it was screen that was leaking, as i
>used to get heaps of swap back when i restarted screen, but i
>see now that this was not the case.

This is caused by the failure of the kernel routine vm_object_collapse() to
discard unneeded vm_objects (e.g. portions of swap space).  Here's something
I mailed to various people about 1.5 years ago:

-start include-
There's a nasty problem with 386bsd's vm code (also present in netrel2, mach
2.5 and even mach 3.0, I believe) where a vm_object can't be collapsed if it
has a pager.  pagers are typically allocated to previously pager-less
objects by the pageout daemon when memory runs short.  This inability to
collapse objects with pagers is quite serious because pager resources
(usually swap space) eventually run out as a result of an enormous string of
un-collapsible vm_objects, each gobbling some amount of swap.

Where does the string of shadow objects come from in the first place?  Each
time a process forks, the object handling it's data segment (for example) is
made into a shadow of two new objects which are given to the parent and the
child of the fork.  When the child exits, the parent still has a shadowed
vm_object.  If nothing in the parent has been paged-out, all is well - a
call to vm_object_collapse() will clobber the shadow object, since no-one
else needs it any more.  Otherwise, the problem described in the previous
paragraph begins.

I have written a program (to be run as root) that produces an vm_object-usage
dump for a given process.  Try it on the sendmail daemon on a heavily loaded
system and see what I mean by vm_objects not being collapsed...
-end include-

FreeBSD 1.5.1 (or thereabouts) largely fixed this problem.  And if anyone
wants a copy of the abovementioned vm_object analyser, just drop me some
mail.

Andrew