Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <34138d9a-5439-5875-ea1b-6584b0c87a67@redhat.com>
Date:   Tue, 2 May 2023 17:21:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Content-Language: en-US
To:     Matthew Wilcox <willy@infradead.org>,
        Mel Gorman <mgorman@techsingularity.net>
Cc:     Johannes Weiner <hannes@cmpxchg.org>, linux-mm@kvack.org,
        Kaiyang Zhao <kaiyang2@cs.cmu.edu>,
        Vlastimil Babka <vbabka@suse.cz>,
        David Rientjes <rientjes@google.com>,
        linux-kernel@vger.kernel.org, kernel-team@fb.com
References: <20230418191313.268131-1-hannes@cmpxchg.org>
 <ZD9qATZcdyW/UGgI@casper.infradead.org>
 <20230421161156.5jnipnfs4svwwzee@techsingularity.net>
 <ZELEgRG5DwmcMB/T@casper.infradead.org>
From:   David Hildenbrand <david@redhat.com>
Organization: Red Hat
Subject: Re: [RFC PATCH 00/26] mm: reliable huge page allocator
In-Reply-To: <ZELEgRG5DwmcMB/T@casper.infradead.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 21.04.23 19:14, Matthew Wilcox wrote:
> On Fri, Apr 21, 2023 at 05:11:56PM +0100, Mel Gorman wrote:
>> It was considered once upon a time and comes up every so often as variants
>> of a "sticky" pageblock pageblock bit that prevents mixing. The risks was
>> ending up in a context where memory within a suitable pageblock cannot
>> be freed and all of the available MOVABLE pageblocks have at least one
>> pinned page that cannot migrate from the allocating context. It can also
>> potentially hit a case where the majority of memory is UNMOVABLE pageblocks,
>> each of which has a single pagetable page that cannot be freed without an
>> OOM kill. Variants of issues like this would manifestas an OOM kill with
>> plenty of memory free bug or excessive CPu usage on reclaim or compaction.
>>
>> It doesn't kill the idea of the series at all but it puts a lot of emphasis
>> in splitting the series by low-risk and high-risk. Maybe to the extent where
>> the absolute protection against mixing can be broken in OOM situations,
>> kernel command line or sysctl.
> 
> Has a variant been previously considered where MOVABLE allocations are
> allowed to come from UNMOVABLE blocks?  After all, MOVABLE allocations
> are generally, well, movable.  So an UNMOVABLE allocation could try to
> migrate pages from a MIXED pageblock in order to turn the MIXED pageblock
> back into an UNMOVABLE pageblock.

I might be completely off, but my understanding was that movable 
allocations can be happily placed into unmovable blocks if required already?

IIRC, it's primarily the zone fallback rules that prevent e.g., ZONE_DMA 
to get filled immediately with movable data in your example. I might eb 
wrong, though.

I guess what you mean is serving movable allocations much earlier from 
these other zones.

Having memory hotunplug in mind ( as always ;) ), I'd expect that such 
fragmentation must be allowed to happen to guarantee that memory (esp. 
ZONE_MOVABLE) can be properly evacuated even if there are not sufficient 
MOVABLE pageblocks around to hold all that (movable) data.

-- 
Thanks,

David / dhildenb