Unlock the object cache before looking for collapse candidates.
Use vm_object_lock_try() to obtain a lock on a collapse candidate.
This avoids a deadlock due to recursively entering
vm_object_deallocate() in case a backing object goes away.
vm_object_collapse() and helper functions:
The object passed in is locked; make sure it is locked when
we leave vm_object_collapse().
XXX: Currently, the object is not unlocked during while we possibly
wait for pager data. We need to consider the effects of
simultaneous calls to vm_object_collapse() on the same object
in case unlocking is necessary.
to describe here. This should fix the problems with "hanging processes"
people have seen since the original object collapse code was committed.
From Charles Hannum <mycroft@netbsd.org>
Create macros (with names borrowed from Mach 3) to manipulate
object->paging_in_progress, and use them. When decreasing the
paging count, always make sure to wake up anyone waiting.
Fixes `vospgc', `vosca1', and `vosca2' hangs.
Make vm_object_prefer() call MD aligner for "pageless" objects too,
so we can have more control over the virtual address to be used.
Implementation could be simpler if we by-pass the object to mapped, but
we'd loose the ability to adapt alignment to objects that were previously
mmap'ed with MAP_FIXED on.
locked page. Make that work. This also obviates the need for vm_fault() to
bogusly activate a page before deactivating it. Finally, make sure the
semantics of vm_object_deactive_pages() don't change.
Here are some fixes I derived from the mach 3.0 VM system a couple of months
ago. At the time, I was giving the memory object routines a good looking
at, trying to fix the long-standing problem where vm_object_collapse()
sometimes fails to collapse objects left over from the exit of a forked
child. As bde has noted, the problem seems to occur when portions of the
parent are paged out. These "lost" memory objects, which can eat up a huge
amount of swap space, are reclaimed when the parent responsible for the
fork()s is killed.
pk