From: Roman Gushchin <guro@fb.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.org>, <linux-mm@kvack.org>,
<kernel-team@fb.com>, <linux-kernel@vger.kernel.org>,
Rik van Riel <riel@surriel.com>,
Mel Gorman <mgorman@techsingularity.net>,
Vlastimil Babka <vbabka@suse.cz>, Qian Cai <cai@lca.pw>,
Andrea Arcangeli <aarcange@redhat.com>,
Joonsoo Kim <js1304@gmail.com>
Subject: Re: [PATCH RFC] mm: compaction: avoid migrating non-cma pages to a cma area
Date: Mon, 13 Apr 2020 09:36:08 -0700 [thread overview]
Message-ID: <20200413163608.GA42877@carbon.lan> (raw)
In-Reply-To: <20200408194119.1076232-1-guro@fb.com>
On Wed, Apr 08, 2020 at 12:41:19PM -0700, Roman Gushchin wrote:
> Compaction does treat cma pageblocks on pair with any movable
> pageblocks. It means it can easily move non-cma pages into a cma zone.
>
> It can create problems for the cma allocator.
>
> The particular problem I'm looking at is related to btrfs metadata
> pages, which are allocated without __GFP_MOVABLE, but beside that
> are generic pagecache pages. In fact, they are sometimes movable
> and sometimes not, depending on whether they are dirty and also
> on the extent buffer reference counter.
>
> Compaction moves them to the hugetlb_cma area, and then sometimes
> the cma allocator fails to move them back from the cma area. It
> results in failures of gigantic hugepages allocations.
>
> Also in general cma areas are reserved close to the end of a zone,
> and it's where compaction tries to migrate pages. It means
> compaction will aggressively fill cma areas, which makes not much
> sense.
>
> So to avoid it, let's preserve non-cma pages from being moved into
> a cma area. Because cma areas are usually quite large and the number
> of areas is small, it should not significantly affect the memory
> fragmentation.
>
> Signed-off-by: Roman Gushchin <guro@fb.com>
Friendly ping... Any thoughts, comments, ideas?
Thanks!
Roman
next prev parent reply other threads:[~2020-04-13 16:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-08 19:41 [PATCH RFC] mm: compaction: avoid migrating non-cma pages to a cma area Roman Gushchin
2020-04-13 16:36 ` Roman Gushchin [this message]
2020-04-14 11:49 ` Vlastimil Babka
2020-04-14 15:42 ` Roman Gushchin
2020-04-17 8:37 ` Vlastimil Babka
2020-04-17 19:21 ` Roman Gushchin
2020-04-20 9:29 ` Vlastimil Babka
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=20200413163608.GA42877@carbon.lan \
--to=guro@fb.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cai@lca.pw \
--cc=js1304@gmail.com \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=riel@surriel.com \
--cc=vbabka@suse.cz \
/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.