hi,

> >> 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.
> 
> so pools never deallocate?  or they only deallocate contiguous chunks
> that won't split a map entry.

storage for pools are allocated/freed with a fixed size
(== PAGE_SIZE for most of pools).  so, if you don't merge entries
or keep merged entries for later use, you'll never need to allocate
entries for "clipping".

> i'm sorry, but i'm becoming a tad confused.  where's the pr for this
> again?  i need to go review the background a little.

see the subject.  PR/24039.

YAMAMOTO Takashi