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

From: Andrew Morton
Date: Mon Mar 15 2004 - 14:06:35 EST


Andrea Arcangeli <andrea@xxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/