From: Johannes Weiner <hannes@cmpxchg.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Mel Gorman <mgorman@techsingularity.net>,
Roman Gushchin <roman.gushchin@linux.dev>,
Rik van Riel <riel@surriel.com>, Joonsoo Kim <js1304@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: [PATCH v2] mm: page_alloc: consume available CMA space first
Date: Wed, 26 Jul 2023 11:07:05 -0400 [thread overview]
Message-ID: <20230726150705.GA1365610@cmpxchg.org> (raw)
In-Reply-To: <20230726145304.1319046-1-hannes@cmpxchg.org>
On a memcache setup with heavy anon usage and no swap, we routinely
see premature OOM kills with multiple gigabytes of free space left:
Node 0 Normal free:4978632kB [...] free_cma:4893276kB
This free space turns out to be CMA. We set CMA regions aside for
potential hugetlb users on all of our machines, figuring that even if
there aren't any, the memory is available to userspace allocations.
When the OOMs trigger, it's from unmovable and reclaimable allocations
that aren't allowed to dip into CMA. The non-CMA regions meanwhile are
dominated by the anon pages.
Movable pages can be migrated out of CMA when necessary, but we don't
have a mechanism to migrate them *into* CMA to make room for unmovable
allocations. The only recourse we have for these pages is reclaim,
which due to a lack of swap is unavailable in our case.
Because we have more options for CMA pages, change the policy to
always fill up CMA first. This reduces the risk of premature OOMs.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
---
mm/page_alloc.c | 53 +++++++++++++++++++------------------------------
1 file changed, 20 insertions(+), 33 deletions(-)
I realized shortly after sending the first version that the code can
be further simplified by removing __rmqueue_cma_fallback() altogether.
Build, boot and runtime tested that CMA is indeed used up first.
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 7d3460c7a480..b257f9651ce9 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1634,17 +1634,6 @@ static int fallbacks[MIGRATE_TYPES][MIGRATE_PCPTYPES - 1] = {
[MIGRATE_RECLAIMABLE] = { MIGRATE_UNMOVABLE, MIGRATE_MOVABLE },
};
-#ifdef CONFIG_CMA
-static __always_inline struct page *__rmqueue_cma_fallback(struct zone *zone,
- unsigned int order)
-{
- return __rmqueue_smallest(zone, order, MIGRATE_CMA);
-}
-#else
-static inline struct page *__rmqueue_cma_fallback(struct zone *zone,
- unsigned int order) { return NULL; }
-#endif
-
/*
* Move the free pages in a range to the freelist tail of the requested type.
* Note that start_page and end_pages are not aligned on a pageblock
@@ -2124,29 +2113,27 @@ __rmqueue(struct zone *zone, unsigned int order, int migratetype,
{
struct page *page;
- if (IS_ENABLED(CONFIG_CMA)) {
- /*
- * Balance movable allocations between regular and CMA areas by
- * allocating from CMA when over half of the zone's free memory
- * is in the CMA area.
- */
- if (alloc_flags & ALLOC_CMA &&
- zone_page_state(zone, NR_FREE_CMA_PAGES) >
- zone_page_state(zone, NR_FREE_PAGES) / 2) {
- page = __rmqueue_cma_fallback(zone, order);
- if (page)
- return page;
- }
+#ifdef CONFIG_CMA
+ /*
+ * Use up CMA first. Movable pages can be migrated out of CMA
+ * if necessary, but they cannot migrate into it to make room
+ * for unmovables elsewhere. The only recourse for them is
+ * then reclaim, which might be unavailable without swap. We
+ * want to reduce the risk of OOM with free CMA space left.
+ */
+ if (alloc_flags & ALLOC_CMA) {
+ page = __rmqueue_smallest(zone, order, MIGRATE_CMA);
+ if (page)
+ return page;
}
-retry:
- page = __rmqueue_smallest(zone, order, migratetype);
- if (unlikely(!page)) {
- if (alloc_flags & ALLOC_CMA)
- page = __rmqueue_cma_fallback(zone, order);
-
- if (!page && __rmqueue_fallback(zone, order, migratetype,
- alloc_flags))
- goto retry;
+#endif
+
+ for (;;) {
+ page = __rmqueue_smallest(zone, order, migratetype);
+ if (page)
+ break;
+ if (!__rmqueue_fallback(zone, order, migratetype, alloc_flags))
+ break;
}
return page;
}
--
2.41.0
next prev parent reply other threads:[~2023-07-26 15:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-26 14:53 [PATCH] " Johannes Weiner
2023-07-26 15:07 ` Johannes Weiner [this message]
2023-07-26 20:06 ` [PATCH v2] " Andrew Morton
2023-07-26 23:38 ` [PATCH] " Roman Gushchin
2023-07-27 8:33 ` Vlastimil Babka
2023-07-27 15:34 ` Johannes Weiner
2023-07-27 17:08 ` Roman Gushchin
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=20230726150705.GA1365610@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=js1304@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=riel@surriel.com \
--cc=roman.gushchin@linux.dev \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox