Subject: Re: kernel map entry merging and PR 24039
To: None <firstname.lastname@example.org>
From: YAMAMOTO Takashi <email@example.com>
Date: 12/04/2004 17:16:55
> >> 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.