Re: [RFC PATCH 00/10] redesign compaction algorithm

[Mel Gorman]

On Fri, Jun 26, 2015 at 11:07:47AM +0900, Joonsoo Kim wrote:
> >> > The long-term success rate of fragmentation avoidance depends on
> >> > minimsing the number of UNMOVABLE allocation requests that use a
> >> > pageblock belonging to another migratetype. Once such a fallback occurs,
> >> > that pageblock potentially can never be used for a THP allocation again.
> >> >
> >> > Lets say there is an unmovable pageblock with 500 free pages in it. If
> >> > the freepage scanner uses that pageblock and allocates all 500 free
> >> > pages then the next unmovable allocation request needs a new pageblock.
> >> > If one is not completely free then it will fallback to using a
> >> > RECLAIMABLE or MOVABLE pageblock forever contaminating it.
> >>
> >> Yes, I can imagine that situation. But, as I said above, we already use
> >> non-movable pageblock for migration scanner. While unmovable
> >> pageblock with 500 free pages fills, some other unmovable pageblock
> >> with some movable pages will be emptied. Number of freepage
> >> on non-movable would be maintained so fallback doesn't happen.
> >>
> >> Anyway, it is better to investigate this effect. I will do it and attach
> >> result on next submission.
> >>
> >
> > Lets say we have X unmovable pageblocks and Y pageblocks overall. If the
> > migration scanner takes movable pages from X then there is more space for
> > unmovable allocations without having to increase X -- this is good. If
> > the free scanner uses the X pageblocks as targets then they can fill. The
> > next unmovable allocation then falls back to another pageblock and we
> > either have X+1 unmovable pageblocks (full steal) or a mixed pageblock
> > (partial steal) that cannot be used for THP. Do this enough times and
> > X == Y and all THP allocations fail.
> 
> This was similar with my understanding but different conclusion.
> 
> As number of unmovable pageblocks, X, which is filled by movable pages
> due to this compaction change increases, reclaimed/migrated out pages
> from them also increase.

There is no guarantee of that, it's timing sensitive and the kernel sepends
more time copying data in/out of the same pageblocks which is wasteful.

> And, then, further unmovable allocation request
> will use this free space and eventually these pageblocks are totally filled
> by unmovable allocation. Therefore, I guess, in the long-term, increasing X
> is saturated and X == Y will not happen.
> 

The whole reason we avoid migrating to unmovable blocks is because it
did happen and quite quickly.  Do not use unmovable blocks as migration
targets. If high-order kernel allocations are required then some reclaim
is necessary for compaction to work with.

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/