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?
>
>see MAX_KMAPENT.

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)",
			    MAX_KMAPENT);
		}
		...

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" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."