On Thu, Jan 27, 2011 at 06:18:07PM -0500, Rik van Riel wrote: > On 01/27/2011 04:31 PM, Mel Gorman wrote: > >> Whatever the final solution, it both needs to prevent too much memory >> being reclaimed and allow kswapd to go to sleep if there is no >> indication from the page allocator that it should stay awake. > > A third requirement: > > If one zone has a lot lower memory pressure than another zone, > we want to do relatively more memory allocations from that zone, > than from a zone where the memory is heavily used. > Risky. Allocations could end up using a lower zone than required causing a form of lowmem pressure when highmem should have been used. Worse, it'll be unnoticable on x86-64 but potentially cause problems on x86-32 that are easily missed. > If kswapd only ever goes up to the high watermark, and also uses > that as its sleep point, the allocations end up corresponding to > zone size alone and not to memory pressure. > hmm. > Going a little bit above the high watermark (1% of zone size? > high + min watermark?) will help balance things out between zones. > >>> if (!zone_watermark_ok_safe(zone, order, >>> - 8*high_wmark_pages(zone), end_zone, 0)) >>> + (zone->present_pages + >>> + KSWAPD_ZONE_BALANCE_GAP_RATIO-1) / >>> + KSWAPD_ZONE_BALANCE_GAP_RATIO + >>> + high_wmark_pages(zone), end_zone, 0)) >> >> Rik has already pointed out that this potentially is a very large gap >> but that is an addressable problem if the final decision goes this >> direction. > > I was wrong. I guess on some systems the min watermark can be less > than 1% and (high + min) may be better, but on most systems the > number of pages should be about the same. > > Maybe we should use high_wmark_pages(zone) + low_wmark_pages(zone) > for easy readability? > I'd be ok with high+low as a starting point to solve the immediate problem of way too much memory being free and then treat "kswapd must go to sleep" as a separate problem. I'm less keen on 1% but only because it could be too large a value. -- Mel Gorman Linux Technology Center IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>