All of lore.kernel.org
 help / color / mirror / Atom feed
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
Date: Tue, 16 Mar 2021 11:26:59 -0700	[thread overview]
Message-ID: <YFD4cz6+0U2jgTzH@google.com> (raw)
In-Reply-To: <YEuiI44IRjBOQ8Wy@google.com>

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


  reply	other threads:[~2021-03-16 18:28 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-10 16:14 [PATCH v3 1/3] mm: replace migrate_prep with lru_add_drain_all Minchan Kim
2021-03-10 16:14 ` [PATCH v3 2/3] mm: disable LRU pagevec during the migration temporarily Minchan Kim
2021-03-11 22:41   ` Chris Goldsworthy
2021-03-14  5:10     ` Chris Goldsworthy
2021-03-12  8:21   ` Michal Hocko
2021-03-12  9:00   ` David Hildenbrand
2021-03-18  0:13   ` Andrew Morton
2021-03-18  1:13     ` Minchan Kim
2021-03-18  8:09     ` Michal Hocko
2021-03-10 16:14 ` [PATCH v3 3/3] mm: fs: Invalidate BH LRU during page migration Minchan Kim
2021-03-12  9:03   ` David Hildenbrand
2021-03-12  9:33     ` David Hildenbrand
2021-03-12 17:17       ` Minchan Kim
2021-03-16 18:26         ` Minchan Kim [this message]
2021-03-17 11:18           ` David Hildenbrand
2021-03-17  2:37   ` [mm] 8fd8d23ab1: WARNING:at_fs/buffer.c:#__brelse kernel test robot
2021-03-17  2:37     ` kernel test robot
2021-03-17 16:29     ` Minchan Kim
2021-03-17 16:29       ` Minchan Kim
2021-03-19 14:05       ` Oliver Sang
2021-03-19 14:05         ` Oliver Sang
2021-03-19 16:47         ` Minchan Kim
2021-03-19 16:47           ` Minchan Kim
2021-03-12  8:19 ` [PATCH v3 1/3] mm: replace migrate_prep with lru_add_drain_all Michal Hocko
2021-03-12  8:53 ` David Hildenbrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YFD4cz6+0U2jgTzH@google.com \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=cgoldswo@codeaurora.org \
    --cc=david@redhat.com \
    --cc=joaodias@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.