Subject: Re: kern/18789: amap_lookups panic after uvm_map changes
To: enami tsugutomo <enami@but-b.or.jp>
From: Andrew Brown <atatat@atatdot.net>
List: netbsd-bugs
Date: 10/24/2002 10:31:53
>> bimerge only currently occurs in the kernel, where no amaps are
>> involved.
>
>Doesn't it occur theoretically, or just stat counter doesn't count up?
currently, since amaps are not extended *backwards*, there's no way to
merge a new entry forwards with an existing entry *if* the following
entry is backed by an amap. a bimerge is simply a new allocation that
filled the gap between two existing allocations. plain forward merges
actually occur rather infrequently.
since kernels don't use amaps, only object references to the kernel
object, forward merges (which are usually bimerges) can occur there.
regular applications typically don't make allocations that are
candidates for forward merges (ie, user space allocations usually
proceed in a forwards direction, are usually backed by amaps, and thus
only incur backmerges).
>> entries involving amaps aren't forward (or bi) merged, only possibly
>> back merged.
>
>I can read the code that forwared merge won't occur if next entry has
>amap, but can't find the code to inhibit bimerge when prev_entry has
>amap.
bimerge is simply a backmerge followed by a forward merge. the
backward merge probably occurs happily, and then the forward merge
fails because the following entry has an amap (if it has nothing
backing it, it will actually succeed, but this is exceedingly rare).
take a look at the stats i gathered over a period of three days at
http://www.graffiti.com/uvm.html
the userspace forward merges and forward merge failures indicated
there were all incurred by a program i specifically wrote to exercise
that code path. note that no bimerges occurred.
>Index: uvm_map.c
>===================================================================
>RCS file: /cvsroot/syssrc/sys/uvm/uvm_map.c,v
>retrieving revision 1.121
>diff -u -r1.121 uvm_map.c
>--- uvm_map.c 2002/10/18 13:18:42 1.121
>+++ uvm_map.c 2002/10/24 13:35:58
>@@ -776,11 +776,10 @@
> UVMCNT_DECR(map_kbackmerge);
> UVMCNT_INCR(map_kbimerge);
> } else {
>- UVMCNT_DECR(map_kbackmerge);
>- UVMCNT_INCR(map_kbimerge);
>+ UVMCNT_DECR(map_ubackmerge);
>+ UVMCNT_INCR(map_ubimerge);
> }
ah. good point. thanks.
>- }
>- else {
>+ } else {
> if (kmap)
> UVMCNT_INCR(map_kforwmerge);
> else
heh. style nits. cool.
--
|-----< "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."