Re: [PATCH v2 4/4] mm, compaction: direct freepage allocation for async direct compaction
From: Vlastimil Babka
Date: Mon Apr 04 2016 - 07:05:32 EST
On 04/04/2016 11:31 AM, Mel Gorman wrote:
On Thu, Mar 31, 2016 at 10:50:36AM +0200, Vlastimil Babka wrote:
The goal of direct compaction is to quickly make a high-order page available
for the pending allocation. The free page scanner can add significant latency
when searching for migration targets, although to succeed the compaction, the
only important limit on the target free pages is that they must not come from
the same order-aligned block as the migrated pages.
What prevents the free pages being allocated from behind the migration
scanner? Having compaction abort when the scanners meet misses
compaction opportunities but it avoids the problem of Compactor A using
pageblock X as a migration target and Compactor B using pageblock X as a
migration source.
It's true that there's no complete protection, but parallel async
compactions should eventually get detect contention and back off. Sync
compaction keeps using the free scanner, so this seemed like a safe
thing to attempt in the initial async compaction, without compromising
success rates thanks to the followup sync compaction.