hi,

> Instead of disabling entry merging for kernel maps, how about the 
> following:
> 
> 	* For every kernel map entry that would be merged and freed,
> 	  merge it, but instead of freeing the map entry, hang it off
> 	  a free list for that map.
> 
> 	* If, when unmapping, you need to allocate a new map entry because
> 	  of a split, pull an entry off that free list.
> 
> 	* Don't use those map entries on the free list for anything other
> 	  than the unmap-split case.
> 
> I guess the only issue then is to determine when free list entries can 
> be freed back when a split is not required on unmap.
> 
> Anyway, I think this, or some variation of this, could solve the 
> problem and still let us have map entry merging for kernel maps.

i've thought about this before the change and suggested on tech-kern.
(and even implemented locally)

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.

YAMAMOTO Takashi