From: Konstantin Khorenko <khorenko@virtuozzo.com>
To: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>,
Vasileios Almpanis <vasileios.almpanis@virtuozzo.com>
Cc: devel@openvz.org
Subject: [Devel] [PATCH hci-8.1 2/3] mm/memcontrol: say where the numa_migrate code comes from
Date: Wed, 28 Oct 2026 14:49:16 +0100 [thread overview]
Message-ID: <20261028-b4-prep-khorenko-vstor-152197-numa-migrate-cleanup-v1-2-aa959eecd3fd@virtuozzo.com> (raw)
In-Reply-To: <20261028-b4-prep-khorenko-vstor-152197-numa-migrate-cleanup-v1-0-aa959eecd3fd@virtuozzo.com>
The comment in the isolation loop tells the rebase history of the code
instead of naming the upstream functions it copies, which is what a
rebase has to compare against. Replace it with those names, name the
original of the allocator too, and drop the leftovers of the copy: the
commented-out conditions and the pre-folio name of the allocator in
the comment to its private argument.
No functional change.
https://virtuozzo.atlassian.net/browse/VSTOR-152197
Feature: mm: interface to migrate memory between NUMA nodes upon userspace request
Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
---
mm/memcontrol.c | 24 +++++++-----------------
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index a82d5e7bc8694..4c3c06cfcf9fc 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3462,7 +3462,7 @@ int ve_enough_memory(long pages)
#ifdef CONFIG_NUMA
/*
- * memcg_numa_migrate_new_page() private argument. @target_nodes specifies the
+ * memcg_numa_migrate_new_folio() private argument. @target_nodes specifies the
* set of nodes to allocate pages from. @current_node is the current preferable
* node, it gets rotated after each allocation.
*/
@@ -3473,7 +3473,8 @@ struct memcg_numa_migrate_struct {
/*
* Used as an argument for migrate_pages(). Allocated pages are spread evenly
- * among destination nodes.
+ * among destination nodes. The order and gfp choice follow
+ * alloc_migration_target().
*/
static struct folio *memcg_numa_migrate_new_folio(struct folio *old_folio,
unsigned long private)
@@ -3520,19 +3521,10 @@ static long memcg_numa_isolate_pages(struct lruvec *lruvec,
scanned++;
/*
- * Previously here we had a call to
- * __isolate_lru_page_prepare(page, ISOLATE_ASYNC_MIGRATE)
- * => need to get same parts from __isolate_lru_page_prepare()
- * like it's done in isolate_migratepages_block() in commit
- * 89f6c88a6ab4 ("mm: __isolate_lru_page_prepare() in
- * isolate_migratepages_block()")
- *
- * The code block below is taken from
- * isolate_migratepages_block(), mode variable is defined and
- * set to ISOLATE_ASYNC_MIGRATE in order to keep the original
- * code unchanged where possible.
- *
- * Also it is switched to folio, based on isolate_lru_folios().
+ * The checks below are a copy of the per-folio checks in
+ * isolate_migratepages_block() with mode == ISOLATE_ASYNC_MIGRATE;
+ * the isolation itself follows isolate_lru_folios(). Keep both
+ * in sync with their originals on a rebase.
*/
folio = lru_to_folio(src);
@@ -3552,7 +3544,6 @@ static long memcg_numa_isolate_pages(struct lruvec *lruvec,
is_unevictable = folio_test_unevictable(folio);
/* Compaction might skip unevictable pages but CMA takes them */
- /* if (is_unevictable) */
if (!(mode & ISOLATE_UNEVICTABLE) && is_unevictable)
goto isolate_fail;
@@ -3567,7 +3558,6 @@ static long memcg_numa_isolate_pages(struct lruvec *lruvec,
is_dirty = folio_test_dirty(folio);
- /* if (is_dirty) */
if (((mode & ISOLATE_ASYNC_MIGRATE) && is_dirty) ||
(mapping && is_unevictable)) {
bool migrate_dirty = true;
--
2.43.0
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
next prev parent reply other threads:[~2026-10-28 13:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-28 13:49 [Devel] [PATCH hci-8.1 0/3] mm/memcontrol: tidy up the memory.numa_migrate code Konstantin Khorenko
2026-10-28 13:49 ` [Devel] [PATCH hci-8.1 1/3] mm/memcontrol: drop the unused update_lru_sizes() Konstantin Khorenko
2026-10-28 13:49 ` Konstantin Khorenko [this message]
2026-10-28 13:49 ` [Devel] [PATCH hci-8.1 3/3] mm/memcontrol: memory.numa_migrate MAX_SCAN counts folios Konstantin Khorenko
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=20261028-b4-prep-khorenko-vstor-152197-numa-migrate-cleanup-v1-2-aa959eecd3fd@virtuozzo.com \
--to=khorenko@virtuozzo.com \
--cc=devel@openvz.org \
--cc=ptikhomirov@virtuozzo.com \
--cc=vasileios.almpanis@virtuozzo.com \
/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.