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;
From:   David Hildenbrand <david@redhat.com>
To:     Minchan Kim <minchan@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>
Cc:     linux-mm <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org>,
        joaodias@google.com, surenb@google.com, cgoldswo@codeaurora.org,
        willy@infradead.org, mhocko@suse.com, vbabka@suse.cz,
        linux-fsdevel@vger.kernel.org
References: <20210310161429.399432-1-minchan@kernel.org>
 <20210310161429.399432-3-minchan@kernel.org>
 <1bdc93e5-e5d4-f166-c467-5b94ac347857@redhat.com>
Organization: Red Hat GmbH
Subject: Re: [PATCH v3 3/3] mm: fs: Invalidate BH LRU during page migration
Message-ID: <1527f16f-4376-a10d-4e72-041926cf38da@redhat.com>
Date:   Fri, 12 Mar 2021 10:33:48 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <1bdc93e5-e5d4-f166-c467-5b94ac347857@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 12.03.21 10:03, David Hildenbrand wrote:
> On 10.03.21 17:14, Minchan Kim wrote:
>> ffer_head LRU caches will be pinned and thus cannot be migrated.
>> This can prevent CMA allocations from succeeding, which are often used
>> on platforms with co-processors (such as a DSP) that can only use
>> physically contiguous memory. It can also prevent memory
>> hot-unplugging from succeeding, which involves migrating at least
>> MIN_MEMORY_BLOCK_SIZE bytes of memory, which ranges from 8 MiB to 1
>> GiB based on the architecture in use.
> 
> Actually, it's memory_block_size_bytes(), which can be even bigger
> (IIRC, 128MiB..2 GiB on x86-64) that fails to get offlined. But that
> will prevent bigger granularity (e.g., a whole DIMM) from getting unplugged.
> 
>>
>> Correspondingly, invalidate the BH LRU caches before a migration
>> starts and stop any buffer_head from being cached in the LRU caches,
>> until migration has finished.
> 
> Sounds sane to me.
> 

Diving a bit into the code, I am wondering:


a) Are these buffer head pages marked as movable?

IOW, are they either PageLRU() or __PageMovable()?


b) How do these pages end up on ZONE_MOVABLE or MIGRATE_CMA?

I assume these pages come via
alloc_page_buffers()->alloc_buffer_head()->kmem_cache_zalloc(GFP_NOFS | 
__GFP_ACCOUNT)


-- 
Thanks,

David / dhildenb