From: Brendan Jackman <jackmanb@google.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Mel Gorman <mgorman@techsingularity.net>,
Michal Hocko <mhocko@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Brendan Jackman <jackmanb@google.com>,
Yosry Ahmed <yosry.ahmed@linux.dev>
Subject: [PATCH v2 2/2] mm/page_alloc: Clarify should_claim_block() commentary
Date: Mon, 24 Feb 2025 12:37:29 +0000 [thread overview]
Message-ID: <20250224-clarify-steal-v2-2-be24da656764@google.com> (raw)
In-Reply-To: <20250224-clarify-steal-v2-0-be24da656764@google.com>
There's lots of text here but it's a little hard to follow, this is an
attempt to break it up and align its structure more closely with the
code.
Reword the top-level function comment to just explain what question the
function answers from the point of view of the caller.
Break up the internal logic into different sections that can have their
own commentary describing why that part of the rationale is present.
Note the page_groupy_by_mobility_disabled logic is not explained in the
commentary, that is outside the scope of this patch...
Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
mm/page_alloc.c | 39 +++++++++++++++++++++++----------------
1 file changed, 23 insertions(+), 16 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 50d6c503474fa4c1d21b5bf5dbfd3eb0eef2c415..547cdba789d8f3f04c5aab04ba7e74cb54c1261b 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1826,16 +1826,9 @@ static void change_pageblock_range(struct page *pageblock_page,
}
/*
- * When we are falling back to another migratetype during allocation, try to
- * claim entire blocks to satisfy further allocations, instead of polluting
- * multiple pageblocks.
- *
- * If we are stealing a relatively large buddy page, it is likely there will be
- * more free pages in the pageblock, so try to claim the whole block. For
- * reclaimable and unmovable allocations, we claim the whole block regardless of
- * page size, as fragmentation caused by those allocations polluting movable
- * pageblocks is worse than movable allocations stealing from unmovable and
- * reclaimable pageblocks.
+ * When we are falling back to another migratetype during allocation, should we
+ * try to claim an entire block to satisfy further allocations, instead of
+ * polluting multiple pageblocks?
*/
static bool should_claim_block(unsigned int order, int start_mt)
{
@@ -1849,6 +1842,26 @@ static bool should_claim_block(unsigned int order, int start_mt)
if (order >= pageblock_order)
return true;
+ /*
+ * Above a certain threshold, always try to claim, as it's likely there
+ * will be more free pages in the pageblock.
+ */
+ if (order >= pageblock_order / 2)
+ return true;
+
+ /*
+ * Unmovable/reclaimable allocations would cause permanent
+ * fragmentations if they fell back to allocating from a movable block
+ * (polluting it), so we try to claim the whole block regardless of the
+ * allocation size. Later movable allocations can always steal from this
+ * block, which is less problematic.
+ */
+ if (start_mt == MIGRATE_RECLAIMABLE || start_mt == MIGRATE_UNMOVABLE)
+ return true;
+
+ if (page_group_by_mobility_disabled)
+ return true;
+
/*
* Movable pages won't cause permanent fragmentation, so when you alloc
* small pages, you just need to temporarily steal unmovable or
@@ -1857,12 +1870,6 @@ static bool should_claim_block(unsigned int order, int start_mt)
* and the next movable allocation may not need to steal. Unmovable and
* reclaimable allocations need to actually claim the whole block.
*/
- if (order >= pageblock_order / 2 ||
- start_mt == MIGRATE_RECLAIMABLE ||
- start_mt == MIGRATE_UNMOVABLE ||
- page_group_by_mobility_disabled)
- return true;
-
return false;
}
--
2.48.1.601.g30ceb7b040-goog
prev parent reply other threads:[~2025-02-24 12:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-24 12:37 [PATCH v2 0/2] mm/page_alloc: Some clarifications for migratetype fallback Brendan Jackman
2025-02-24 12:37 ` [PATCH v2 1/2] mm/page_alloc: Clarify terminology in migratetype fallback code Brendan Jackman
2025-02-24 18:42 ` Brendan Jackman
2025-02-25 11:05 ` Vlastimil Babka
2025-02-24 12:37 ` Brendan Jackman [this message]
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=20250224-clarify-steal-v2-2-be24da656764@google.com \
--to=jackmanb@google.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=vbabka@suse.cz \
--cc=yosry.ahmed@linux.dev \
/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