On Tue, Jul 29, 2014 at 05:34:37PM +0200, Vlastimil Babka wrote:
Could do it in isolate_migratepages() for whole pageblocks only (as
David's patch did), but that restricts the usefulness. Or maybe do
it fine grained by calling isolate_migratepages_block() multiple
times. But the overhead of multiple calls would probably suck even
more for lower-order compactions. For CMA the added overhead is
basically only checks for next_capture_pfn that will be always
false, so predictable. And mostly just in branches where isolation
is failing, which is not the CMA's "fast path" I guess?
You can do it find grained with compact_control's migratepages list
or new private list. If some pages are isolated and added to this list,
you can check pfn of page on this list and determine appropriate capture
candidate page. This approach can give us more flexibility for
choosing capture candidate without adding more complexity to
common function. For example, you can choose capture candidate if
there are XX isolated pages in certain range.
In __isolate_free_page(), we check zone_watermark_ok() with order 0.
But normal allocation logic would check zone_watermark_ok() with requested
order. Your capture logic uses __isolate_free_page() and it would
affect compaction success rate significantly. And it means that
capture logic allocates high order page on page allocator
too aggressively compared to other component such as normal high order
It's either that, or the extra lru drain that makes the different.
But the "aggressiveness" would in fact mean better accuracy.
Watermark checking may be inaccurate. Especially when memory is
close to the watermark and there is only a single high-order page
that would satisfy the allocation.
If this "aggressiveness" means better accuracy, fixing general
function, watermark_ok() is better than adding capture logic.
But, I guess that there is a reason that watermark_ok() is so
conservative. If page allocator aggressively provides high order page,
future atomic high order page request cannot succeed easily. For
preventing this situation, watermark_ok() should be conservative.