On Sat, Feb 17, 2001 at 10:12:50AM -0500, Lennart Augustsson wrote:

 > every time:
 > extent_free
 > uvm_swap_free
 > uvm_anon_dropswap

It would be nice to put a breakpoint at uvm_anon_dropswap and see if it's
getting into extent_free many times, or if it's really looping in extent_free.

 > uvm_anfree
 > amap_wipeout
 > amap_unref
 > uvm_unmap_detach
 > uvm_unmap
 > uvm_deallocate
 > exit1
 > sigexit
 > 
 > So it seems that we have a severe algorithmic problem in extent_free
 > (or just a plain bug?).  I didn't look much more at it, but it looks to me
 > like removing all entries from an extent map is quadratic, so if the map
 > grows large this could be a problem.
 > 
 >     -- Lennart
 > 
 > 
 > Chuck Silvers wrote:
 > 
 > > sorry, I missed the part about no disk activity.
 > > this sounds a bit different from problems I've heard of.
 > >
 > > -Chuck
 > >
 > > On Sun, Feb 04, 2001 at 03:20:28PM -0500, Lennart Augustsson wrote:
 > > > Yes, my tree is very up-todate.  I've had this problem ever since UBC was
 > > > integrated.  It's not the same as the problem Jason fixed.  Jason's fix makes
 > > > interactive response better under heavly load.  Note that when my machine
 > > > freezes there is NO disk activity.
 > > >
 > > >     -- Lennart
 > 
 > 

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>