Re: [RFC PATCH 0/2] avoid external fragmentation related to migration fallback

[Mel Gorman]

On Fri, Jan 29, 2016 at 10:03:52PM +0100, Vlastimil Babka wrote:
> > Since the root cause is that fallbacks might frequently split order-2
> > and order-3 pages of the other migration types. This patch tweaks
> > fallback mechanism to avoid splitting order-2 and order-3 pages. while
> > fallbacks happen, if the largest feasible pages are less than or queal to
> > COSTLY_ORDER, i.e. 3, then try to select the smallest feasible pages. The
> > reason why fallbacks prefer the largest feasiable pages is to increase
> > fallback efficiency since fallbacks are likely to happen again. By
> > stealing the largest feasible pages, it could reduce the oppourtunities
> > of antoher fallback. Besides, it could make consecutive allocations more
> > approximate to each other and make system less fragment. However, if the
> > largest feasible pages are less than or equal to order-3, fallbacks might
> > split it and make the upcoming order-3 page allocations fail.
> 
> In theory I don't see immediately why preferring smaller pages for
> fallback should be a clear win. If it's Unmovable allocations stealing
> from Movable pageblocks, the allocations will spread over larger areas
> instead of being grouped together. Maybe, for Movable allocations
> stealing from Unmovable allocations, preferring smallest might make
> sense and be safe, as any extra fragmentation is fixable bycompaction.

I strongly agree that spreading the fallback allocations over a larger
area is likely to have a negative impact. Given the age of the kernel
being tested, it would make sense to either rebase or at the very last
backport the patches that affect watermark calculations and the
treatment of high-order pages.

-- 
Mel Gorman
SUSE Labs