On Sun, May 01, 2005 at 07:49:16PM +0900, YAMAMOTO Takashi wrote:
> 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
> 
> i don't think it's a new problem.
> how do you think about preventing amap extended beyond some threshold as
> the following?  (UVM_AMAP_LARGE might be too small for this purpose.)

I haven't tried the patch, but I think something like this would be good.
UVM_AMAP_LARGE is the max we'll allocate in amap_copy(), so I think it
would be good for this other purpose as well.  really the intent in both
contexts is the same, so it makes sense to use the same threshold.


> ideally we might be able to merge entries in fault handler.
> although i don't want to put such complexity there.

I'd think this would be fine.  as long as we can fail gracefully
(ie. just leave things more fragmented) if we can't get the memory
to merge the entries, there shouldn't be a problem with doing this
at fault time vs. at any other time.

-Chuck