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;
Sender: Minchan Kim <minchan.kim@gmail.com>
Date:   Tue, 16 Mar 2021 11:26:59 -0700
From:   Minchan Kim <minchan@kernel.org>
To:     David Hildenbrand <david@redhat.com>,
        Andrew Morton <akpm@linux-foundation.org>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        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
Subject: Re: [PATCH v3 3/3] mm: fs: Invalidate BH LRU during page migration
Message-ID: <YFD4cz6+0U2jgTzH@google.com>
References: <20210310161429.399432-1-minchan@kernel.org>
 <20210310161429.399432-3-minchan@kernel.org>
 <1bdc93e5-e5d4-f166-c467-5b94ac347857@redhat.com>
 <1527f16f-4376-a10d-4e72-041926cf38da@redhat.com>
 <YEuiI44IRjBOQ8Wy@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YEuiI44IRjBOQ8Wy@google.com>
Precedence: bulk

On Fri, Mar 12, 2021 at 09:17:23AM -0800, Minchan Kim wrote:
> On Fri, Mar 12, 2021 at 10:33:48AM +0100, David Hildenbrand wrote:
> > 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)
> > 
> 
> It's indirect it was not clear
> 
> try_to_release_page
>     try_to_free_buffers
>         buffer_busy
>             failed
> 
> Yeah, comment is misleading. This one would be better.
> 
>         /*
>          * the refcount of buffer_head in bh_lru prevents dropping the
>          * attached page(i.e., try_to_free_buffers) so it could cause
>          * failing page migrationn.
>          * Skip putting upcoming bh into bh_lru until migration is done.
>          */

Hi Andrew,

Could you fold this comment fix patch? If you prefer formal patch,
let me know. I will resend it.

Thank you.

From 0774f21e2dc8220fc2be80c25f711cb061363519 Mon Sep 17 00:00:00 2001
From: Minchan Kim <minchan@kernel.org>
Date: Fri, 12 Mar 2021 09:17:34 -0800
Subject: [PATCH] comment fix

Signed-off-by: Minchan Kim <minchan@kernel.org>
---
 fs/buffer.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/buffer.c b/fs/buffer.c
index ca9dd736bcb8..8602dcbe0327 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1265,8 +1265,9 @@ static void bh_lru_install(struct buffer_head *bh)
 
 	check_irqs_on();
 	/*
-	 * buffer_head in bh_lru could increase refcount of the page
-	 * until it will be invalidated. It causes page migraion failure.
+	 * the refcount of buffer_head in bh_lru prevents dropping the
+	 * attached page(i.e., try_to_free_buffers) so it could cause
+	 * failing page migratoin.
 	 * Skip putting upcoming bh into bh_lru until migration is done.
 	 */
 	if (lru_cache_disabled())
-- 
2.31.0.rc2.261.g7f71774620-goog