![]() | |||||||||||||
Messages in this thread |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 13:01 [from the cache] ©2003-2008 | |||||||||||||