Subject: Re: kernel map entry merging and PR 24039
To: YAMAMOTO Takashi <>
From: Andrew Brown <>
List: tech-kern
Date: 12/03/2004 20:18:57
On Fri, Dec 03, 2004 at 02:38:48PM +0900, YAMAMOTO Takashi wrote:
>> >and of course, regardless of what pmap(1) shows, you always have
>> >>=1000 reserved entries.
>> i do?  where?

ah, in this clause:

	if (map->flags & VM_MAP_INTRSAFE || cold) {
		if (__predict_false(me == NULL)) {
			panic("uvm_mapent_alloc: out of static map entries, "
			    "check MAX_KMAPENT (currently %d)",

VM_MAP_INTRSAFE is only set for (afaict) the kmem_map submap and
mb_map submap, and cold is only true until clocks are started.

>> 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.

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.

|-----< "CODE WARRIOR" >-----|             * "ah!  i see you have the internet (Andrew Brown)                that goes *ping*!"       * "information is power -- share the wealth."