> >and of course, regardless of what pmap(1) shows, you always have
> >>=1000 reserved entries.
> 
> i do?  where?

see MAX_KMAPENT.

> the main point is that whether you merge or not, you can *always* get
> into a situation where you need to allocate in order to de-allocate.
> 
> there's nothing stopping me from allocating three contiguous pages
> (covered by one map entry) and then freeing the middle one when
> there's no free memory left.  not merging map entries when possible
> simply makes this more likely, afaict.

we're talking about pool(9) and its friends, which never do such a thing.

YAMAMOTO Takashi