Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH] mm/page_alloc: don't corrupt pcppage_migratetype
To:     Doug Berger <opendmb@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>
Cc:     Mel Gorman <mgorman@techsingularity.net>,
        "Peter Zijlstra (Intel)" <peterz@infradead.org>,
        linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        Joonsoo Kim <iamjoonsoo.kim@lge.com>
References: <20210811182917.2607994-1-opendmb@gmail.com>
 <e9393682-5429-448a-d151-a3ee05216499@suse.cz>
 <b5020966-c7dd-54b2-9e6a-e1d21a23d267@gmail.com>
From:   Vlastimil Babka <vbabka@suse.cz>
Message-ID: <a4a1344d-8b67-cc7f-2b28-6d9c2fd2c62d@suse.cz>
Date:   Thu, 19 Aug 2021 15:09:41 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <b5020966-c7dd-54b2-9e6a-e1d21a23d267@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 8/13/21 2:21 AM, Doug Berger wrote:
> On 8/12/2021 1:17 AM, Vlastimil Babka wrote:
>> On 8/11/21 8:29 PM, Doug Berger wrote:
>>> When placing pages on a pcp list, migratetype values over
>>> MIGRATE_PCPTYPES get added to the MIGRATE_MOVABLE pcp list.
>>>
>>> However, the actual migratetype is preserved in the page and
>>> should not be changed to MIGRATE_MOVABLE or the page may end
>>> up on the wrong free_list.
>>
>> Nice, how did you find out? Were there any user-visible effects? (Hint: which?
>> the changelog should say that so that the severity of the bug can be judged).
>> Otherwise I agree the bug is there and patch is fixing it. Thanks.
> 
> I did not observe the bug "in the wild", but rather noticed it while
> reviewing the current CMA implementation. I would imagine in the worst
> case that CMA memory could leak onto MIGRATE_MOVABLE free_lists and get
> "stolen" through fallback for MIGRATE_UNMOVABLE allocations effectively
> breaking CMA.

Right, thanks.

> For full disclosure I should take this opportunity to say that I am
> investigating ways to improve the CMA/Movable memory implementations
> somewhat in line with what Joonsoo Kim has been trying, which is why I
> observed this bug.
> 
> However, I largely agree with the proposal Mel Gorman made in his
> comments on:
> https://lkml.org/lkml/2016/4/28/244
> 
> I can appreciate that zones may provide a convenient way of grouping
> memory with common attributes, but it is a bastardization of the
> original intention of zones. I would prefer a mechanism for designating
> blocks of memory as "sticky" movable such that they can only be used to
> satisfy movable memory requests and not be converted to other
> migratetypes. I've wrestled with the terminology and currently favor
> Designated Movable Blocks (as opposed to "sticky") because these are
> blocks of memory that have the movable attribute by designation rather
> than by default or accident.
> 
> While CMA blocks should be a subset of Designated Movable Blocks since
> they have the same migration properties, it may be desirable/necessary
> to maintain a distinction to accommodate competing allocation
> objectives. Specifically, Designated Movable Blocks used by CMA to
> satisfy the needs of drivers will likely want the page allocator to be
> less aggressive than users of Memory Hot-plug or kernelcore= Designated
> Movable Blocks. Perhaps a round-robin scheme with MIGRATE_MOVABLE can
> satisfy all users, but I'm not too optimistic.

I was, on the other hand, in favor Joonsoo's zone based solution, as
there's always problems with these designated pageblocks and watermarks.
It's also described in the thread you linked above. See
__zone_watermark_unusable_free() how it has to subtract
NR_FREE_CMA_PAGES for non-movable allocations. So you need to track
NR_FREE_CMA_PAGES which is rather fragile, and then reclaim target
depends on whether your goal is movable or unmovable allocation. Either
it's movable and you might end up in free memory only in those
designated-movable (today, MIGRATE_CMA) blocks, and unmovable allocation
has to direct reclaim and hope the reclaimed LRU pages will be in the
"normal" pageblocks, or you make sure that there's enough free pages in
normal pageblocks, and end up with lower memory utilization. A separate
zone solves this problem.

> I don't know if Mel has changed his opinions on this matter, but any
> suggestions and encouragement are appreciated.
> 
> Thanks,
>     Doug