On Wed, 16 Feb 2011 09:50:49 +0000
Mel Gorman [off-list ref] wrote:

should_continue_reclaim() for reclaim/compaction allows scanning to continue
even if pages are not being reclaimed until the full list is scanned. In
terms of allocation success, this makes sense but potentially it introduces
unwanted latency for high-order allocations such as transparent hugepages
and network jumbo frames that would prefer to fail the allocation attempt
and fallback to order-0 pages.  Worse, there is a potential that the full
LRU scan will clear all the young bits, distort page aging information and
potentially push pages into swap that would have otherwise remained resident.

afaict the patch affects order-0 allocations as well.  What are the
implications of this?

Also, what might be the downsides of this change, and did you test for
them?

This patch will stop reclaim/compaction if no pages were reclaimed in the
last SWAP_CLUSTER_MAX pages that were considered.

a) Why SWAP_CLUSTER_MAX?  Is (SWAP_CLUSTER_MAX+7) better or worse?

b) The sentence doesn't seem even vaguely accurate.  shrink_zone()
   will scan vastly more than SWAP_CLUSTER_MAX pages before calling
   should_continue_reclaim().  Confused.

c) The patch doesn't "stop reclaim/compaction" fully.  It stops it
   against one zone.  reclaim will then advance on to any other
   eligible zones.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>