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
next prev parent reply other threads:[~2021-03-16 18:28 UTC|newest]
Thread overview: 21+ 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 16:29 ` Minchan Kim
2021-03-19 14:05 ` Oliver Sang
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).