Subject: Re: Freeing swap space is slooooooooow
To: None <tech-kern@netbsd.org>
From: Chuck Silvers <chuq@chuq.com>
List: tech-kern
Date: 09/22/2001 15:18:59
someone requested that I point out that I recently checked in a change
that works around the problem described below.  the work-around is:

Module Name:    syssrc
Committed By:   chs
Date:           Wed Sep 19 03:41:46 UTC 2001

Modified Files:
        syssrc/sys/uvm: uvm_amap.c

Log Message:
work around swap-space/extent performance problem which causes
long pauses when processes with lots of swapped-out pages exit.


To generate a diff of this commit:
cvs rdiff -r1.34 -r1.35 syssrc/sys/uvm/uvm_amap.c



the effect of this is that it still takes just as much cputime to
free up the swap space, but this no longer starves other processes
so you don't really notice it.  this can of course be removed when
the underlying algorithmic problem with swap space and extents is fixed.

-Chuck


On Sun, Feb 25, 2001 at 10:25:10PM -0500, Lennart Augustsson wrote:
> Well, I've found the reason why my machine goes catatonic far a few seconds
> now and then.
> 
> At some point someone decided to use extent maps to keep track of swap
> space.  This might look like a good decision, but it was obviously not tested
> for performance.  Here are some typical figures:
> 
> amap_wipeout: 4604442 usec, 19233 extent_free calls, 26596209 loops
> amap_wipeout: 2065357 usec, 9093 extent_free calls, 11504939 loops
> amap_wipeout: 4947341 usec, 19475 extent_free calls, 27719989 loops
> amap_wipeout: 1451860 usec, 6012 extent_free calls, 7919861 loops
> amap_wipeout: 2856252 usec, 10727 extent_free calls, 14612941 loops
> amap_wipeout: 3978208 usec, 12350 extent_free calls, 18281796 loops
> amap_wipeout: 1414115 usec, 4196 extent_free calls, 6308825 loops
> amap_wipeout: 1934060 usec, 5735 extent_free calls, 8818042 loops
> amap_wipeout: 1373972 usec, 3923 extent_free calls, 6141905 loops
> 
> The usec is the number of microseconds to complete an amap_wipeout
> (which gets frees swap space), extent_free calls is the number of calls
> to extent_free(), and loops is the number of iteration through the loop
> in extent_free().
> 
> 25 miilion loops, 5s for a process to exit!?!?!  It's so bad it's not even funny.
> 
> Either the extent maps have to be improved, or some other data structure
> has to be used.
> 
>     -- Lennart
>