Re: [RFC 3/3] mm, compaction: introduce deferred async compaction

[Mel Gorman <mgorman@techsingularity.net>]

On Tue, Dec 11, 2018 at 03:29:41PM +0100, Vlastimil Babka wrote:
> Deferring compaction happens when it fails to fulfill the allocation request at
> given order, and then a number of the following direct compaction attempts for
> same or higher orders is skipped; with further failures, the number grows
> exponentially up to 64. This is reset e.g. when compaction succeeds.
> 
> Until now, defering compaction is only performed after a sync compaction fails,
> and then it also blocks async compaction attempts. The rationale is that only a
> failed sync compaction is expected to fully exhaust all compaction potential of
> a zone. However, for THP page faults that use __GFP_NORETRY, this means only
> async compaction is attempted and thus it is never deferred, potentially
> resulting in pointless reclaim/compaction attempts in a badly fragmented node.
> 
> This patch therefore tracks and checks async compaction deferred status in
> addition, and mostly separately from sync compaction. This allows deferring THP
> fault compaction without affecting any sync pageblock-order compaction.
> Deferring for sync compaction however implies deferring for async compaction as
> well. When deferred status is reset, it is reset for both modes.
> 
> The expected outcome is less compaction/reclaim activity for failing THP faults
> likely with some expense on THP fault success rate.
> 

Either pre/post compaction series I think this makes sense although the
details may change slightly. If the caller allows then do async
compaction, sync compaction if that fails and defer if that also fails.
If the caller can only do async compaction then defer upon failure and
keep track of those two callers separetly.

-- 
Mel Gorman
SUSE Labs