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.