Re: [2.4] heavy-load under swap space shortage

Andrea Arcangeli
2004-03-15T21:56:09Z

On Mon, Mar 15, 2004 at 11:02:40AM -0800, Andrew Morton wrote:
> Andrea Arcangeli <andrea@suse.de> wrote:
> >
> > The effect is that you can do stuff like 'cvs up' and you will end up
> > caching just 1G instead of 2G. Or do I miss something? If I would own a
> > 2G box I would hate to be able to cache just 1 G (yeah, the cache is 2G
> > but half of that cache is pinned and it sits there with years old data,
> > so effectively you lose 50% of the ram in the box in terms of cache
> > utilization).
>
> Nope, we fill all zones with pagecache and once they've all reached
> pages_low we scan all zones in proportion to their size. So the
> probability of a page being scanned is independent of its zone.
>
> It took a bit of diddling, but it seems to work OK now. Here are the
> relevant bits of /proc/vmstat from a 1G machine, running 2.6.4-rc1-mm1 with
> 13 days uptime:
>
> pgalloc_high 65658111
> pgalloc_normal 384294820
> pgalloc_dma 617780
>
> pgrefill_high 5980273
> pgrefill_normal 11873490
> pgrefill_dma 69861
>
> pgsteal_high 2377905
> pgsteal_normal 10504356
> pgsteal_dma 4756
>
> pgscan_kswapd_high 3621882
> pgscan_kswapd_normal 15652593
> pgscan_kswapd_dma 99
>
> pgscan_direct_high 54120
> pgscan_direct_normal 162353
> pgscan_direct_dma 69377
>
> These are approximately balanced wrt the zone sizes, with a bias towards
> ZONE_NORMAL because of non-highmem allocations. It's not perfect, but we
> did fix a few things up after 2.6.4-rc1-mm1.

as far as you don't always start from the highmem zone (so you need a
per-classzone variable to keep track of the last zone scanned and to
start shrinking from zone-normal and zone-dma if needed), the above
should avoid the problem I mentioned for the 2G setup.