Subject: deferred amap allocation (Re: CVS commit: src/sys/uvm)
To: YAMAMOTO Takashi <yamt@netbsd.org>
From: Chuck Silvers <chuq@chuq.com>
List: tech-kern
Date: 04/30/2005 16:48:17
hi,

what does this do if a new, large map entry can be merged with an existing
small map entry that has an amap allocated?  if the large one is 1 GB
and the small one is one page, does this allocate amap space for the whole
1 GB?  that seems undesirable.  (I haven't looked at the code so maybe
we avoid this somewhere else, but I thought I'd ask.)

-Chuck


On Fri, Apr 29, 2005 at 09:05:21AM +0000, YAMAMOTO Takashi wrote:
> 
> Module Name:	src
> Committed By:	yamt
> Date:		Fri Apr 29 09:05:21 UTC 2005
> 
> Modified Files:
> 	src/sys/uvm: uvm_map.c
> 
> Log Message:
> uvm_map_enter: don't bother to defer amap allocation if there's a mergable
> existing entry.  although there're merits and demerits, i think it benefits
> common cases.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -r1.189 -r1.190 src/sys/uvm/uvm_map.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.