Message-ID: <20170531083145.2s5pk5zhkf2kh4ga@techsingularity.net>
Date:   Wed, 31 May 2017 09:31:45 +0100
From:   Mel Gorman <mgorman@...hsingularity.net>
To:     Vlastimil Babka <vbabka@...e.cz>
Cc:     Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, Johannes Weiner <hannes@...xchg.org>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        David Rientjes <rientjes@...gle.com>
Subject: Re: [PATCH] mm, page_alloc: fallback to smallest page when not
 stealing whole pageblock

On Mon, May 29, 2017 at 11:39:47AM +0200, Vlastimil Babka wrote:
> Since commit 3bc48f96cf11 ("mm, page_alloc: split smallest stolen page in
> fallback") we pick the smallest (but sufficient) page of all that have been
> stolen from a pageblock of different migratetype. However, there are cases when
> we decide not to steal the whole pageblock. Practically in the current
> implementation it means that we are trying to fallback for a MIGRATE_MOVABLE
> allocation of order X, go through the freelists from MAX_ORDER-1 down to X, and
> find free page of order Y. If Y is less than pageblock_order / 2, we decide not
> to steal all pages from the pageblock. When Y > X, it means we are potentially
> splitting a larger page than we need, as there might be other pages of order Z,
> where X <= Z < Y. Since Y is already too small to steal whole pageblock,
> picking smallest available Z will result in the same decision and we avoid
> splitting a higher-order page in a MIGRATE_UNMOVABLE or MIGRATE_RECLAIMABLE
> pageblock.
> 
> This patch therefore changes the fallback algorithm so that in the situation
> described above, we switch the fallback search strategy to go from order X
> upwards to find the smallest suitable fallback. In theory there shouldn't be
> a downside of this change wrt fragmentation.
> 
> This has been tested with mmtests' stress-highalloc performing GFP_KERNEL
> order-4 allocations, here is the relevant extfrag tracepoint statistics:
> 
>                                                       4.12.0-rc2      4.12.0-rc2
>                                                        1-kernel4       2-kernel4
> Page alloc extfrag event                                  25640976    69680977
> Extfrag fragmenting                                       25621086    69661364
> Extfrag fragmenting for unmovable                            74409       73204
> Extfrag fragmenting unmovable placed with movable            69003       67684
> Extfrag fragmenting unmovable placed with reclaim.            5406        5520
> Extfrag fragmenting for reclaimable                           6398        8467
> Extfrag fragmenting reclaimable placed with movable            869         884
> Extfrag fragmenting reclaimable placed with unmov.            5529        7583
> Extfrag fragmenting for movable                           25540279    69579693
> 
> Since we force movable allocations to steal the smallest available page (which
> we then practially always split), we steal less per fallback, so the number of
> fallbacks increases and steals potentially happen from different pageblocks.
> This is however not an issue for movable pages that can be compacted.
> 

Way back I was worried that more fragmenting events for movable like
this may lead to more unmovable fragmenting events and increase overall
fragmentation. At the time, it was also the case that I was mostly testing
32-bit and smaller memory sizes but that is now obviously different and the
mix of high-order allocation sizes has also changed considerably. Also,
while your data indicates there are more fragmenting events, there are
fewer for unmovable allocations so the data supports your position. Hence,
I can't backup by concerns other than with vague hand-waving about vague
recollections from 10 years ago so

Acked-by: Mel Gorman <mgorman@...hsingularity.net>

-- 
Mel Gorman
SUSE Labs

Powered by blists - more mailing lists