From: Chris Goldsworthy <cgoldswo@codeaurora.org>
To: Minchan Kim <minchan@kernel.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, willy@infradead.org,
mhocko@suse.com, david@redhat.com, vbabka@suse.cz,
linux-fsdevel@vger.kernel.org,
Minchan Kim <minchan.kim@gmail.com>
Subject: Re: [PATCH v3 2/3] mm: disable LRU pagevec during the migration temporarily
Date: Thu, 11 Mar 2021 14:41:30 -0800 [thread overview]
Message-ID: <623d54ccbd5324bff22ad1389eae38f4@codeaurora.org> (raw)
In-Reply-To: <20210310161429.399432-2-minchan@kernel.org>
On 2021-03-10 08:14, Minchan Kim wrote:
> LRU pagevec holds refcount of pages until the pagevec are drained.
> It could prevent migration since the refcount of the page is greater
> than the expection in migration logic. To mitigate the issue,
> callers of migrate_pages drains LRU pagevec via migrate_prep or
> lru_add_drain_all before migrate_pages call.
>
> However, it's not enough because pages coming into pagevec after the
> draining call still could stay at the pagevec so it could keep
> preventing page migration. Since some callers of migrate_pages have
> retrial logic with LRU draining, the page would migrate at next trail
> but it is still fragile in that it doesn't close the fundamental race
> between upcoming LRU pages into pagvec and migration so the migration
> failure could cause contiguous memory allocation failure in the end.
>
> To close the race, this patch disables lru caches(i.e, pagevec)
> during ongoing migration until migrate is done.
>
> Since it's really hard to reproduce, I measured how many times
> migrate_pages retried with force mode(it is about a fallback to a
> sync migration) with below debug code.
>
> int migrate_pages(struct list_head *from, new_page_t get_new_page,
> ..
> ..
>
> if (rc && reason == MR_CONTIG_RANGE && pass > 2) {
> printk(KERN_ERR, "pfn 0x%lx reason %d\n", page_to_pfn(page),
> rc);
> dump_page(page, "fail to migrate");
> }
>
> The test was repeating android apps launching with cma allocation
> in background every five seconds. Total cma allocation count was
> about 500 during the testing. With this patch, the dump_page count
> was reduced from 400 to 30.
>
> The new interface is also useful for memory hotplug which currently
> drains lru pcp caches after each migration failure. This is rather
> suboptimal as it has to disrupt others running during the operation.
> With the new interface the operation happens only once. This is also in
> line with pcp allocator cache which are disabled for the offlining as
> well.
>
> Signed-off-by: Minchan Kim <minchan@kernel.org>
> ---
Hi Minchan,
This all looks good to me - feel free to add a Reviewed-by from me.
Thanks,
Chris.
--
The Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2021-03-11 22:42 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 [this message]
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
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=623d54ccbd5324bff22ad1389eae38f4@codeaurora.org \
--to=cgoldswo@codeaurora.org \
--cc=akpm@linux-foundation.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=minchan.kim@gmail.com \
--cc=minchan@kernel.org \
--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).