>however, i concluded that it didn't work.  
>a split can occur even if you didn't merge entries
>(eg. when you map [0..100] and then unmap [10..90].
>of course, one doing such a thing can't assume unmap won't block.)
>and it can consume "reserved" entries for merged maps which are
>expected to be unmapped without blocking.

if the problem was uvm_unmap() sleeping when unmapping something
because it needed to allocate a new vm_map_entry in order to perform a
split, your example above demonstrates that disabling merging cannot
solve the problem because merging could not have led to your
configuration above in the first place.

the only reason that i can think of that turning off merging would
have a "winful" effect would be that it keep pressure higher on the
amount of space that can be consumed by vm_map_entries, thereby
leading to a greater likelihood that one has just been released or
that there is space for one more.

that sounds kinda bogus, though.

now...granted, i don't have all that much running, but i really think
that this:

	% pmap -l [1-9]* | grep -v ^p | wc -l
	    1589
	% pmap -l 0 | wc -l
	    2603

should not be the case.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."