From: Joanne Koong <joannelkoong@gmail.com>
To: akpm@linux-foundation.org, hannes@cmpxchg.org,
shakeel.butt@linux.dev, roman.gushchin@linux.dev,
willy@infradead.org, jack@suse.cz
Cc: mhocko@suse.com, muchun.song@linux.dev, david@kernel.org,
ljs@kernel.org, vbabka@kernel.org, liam@infradead.org,
rppt@kernel.org, surenb@google.com, riel@surriel.com,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: [PATCH v1 1/3] mm: memcontrol: factor reclaim logic out of try_charge_memcg()
Date: Fri, 2 Oct 2026 17:15:53 -0700 [thread overview]
Message-ID: <20261003001555.3498357-2-joannelkoong@gmail.com> (raw)
In-Reply-To: <20261003001555.3498357-1-joannelkoong@gmail.com>
Move reclaim logic in try_charge_memcg() into helper functions so that
the next patch can reuse them.
In memcg_charge_reclaim(), we can call memcg_memory_event() directly
instead of passing in allow_spinning. allow_spinning must always be true
here since memcg_charge_may_reclaim() has already checked that the gfp
mask allows blocking, which implies spinning is also allowed.
No functional changes.
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
---
mm/memcontrol.c | 67 +++++++++++++++++++++++++++++++------------------
1 file changed, 43 insertions(+), 24 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index aad0498a7bd6..1d4b603085a5 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2696,6 +2696,46 @@ void __mem_cgroup_handle_over_high(gfp_t gfp_mask)
css_put(&memcg->css);
}
+static bool memcg_charge_may_reclaim(gfp_t gfp_mask)
+{
+ if (unlikely(task_in_memcg_oom(current)))
+ return false;
+
+ if (!gfpflags_allow_blocking(gfp_mask))
+ return false;
+
+ /*
+ * OOM victim still needs to charge memory to exit. OOM reaper should
+ * help but it might fail on mmap_lock contention. If the victim is a
+ * large thread group then all exiting threads might compete on oom_lock
+ * just to learn that there is nothing really killable anymore. Bail
+ * out early and fail the charge to expedite their exit. They are
+ * considered fully reclaimed by the oom reaper and they shouldn't
+ * contribute further charges.
+ */
+ if (tsk_is_oom_victim(current) &&
+ mm_flags_test(MMF_OOM_SKIP, current->signal->oom_mm))
+ return false;
+
+ return true;
+}
+
+static unsigned long memcg_charge_reclaim(struct mem_cgroup *memcg,
+ unsigned long nr_pages,
+ gfp_t gfp_mask,
+ unsigned int reclaim_options)
+{
+ unsigned long nr_reclaimed, pflags;
+
+ memcg_memory_event(memcg, MEMCG_MAX);
+ psi_memstall_enter(&pflags);
+ nr_reclaimed = try_to_free_mem_cgroup_pages(memcg, nr_pages, gfp_mask,
+ reclaim_options, NULL);
+ psi_memstall_leave(&pflags);
+
+ return nr_reclaimed;
+}
+
static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask,
unsigned int nr_pages)
{
@@ -2708,7 +2748,6 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask,
unsigned int reclaim_options;
bool drained = false;
bool raised_max_event = false;
- unsigned long pflags;
bool allow_spinning = gfpflags_allow_spinning(gfp_mask);
int ret = 0;
@@ -2747,33 +2786,13 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask,
if (unlikely(current->flags & PF_MEMALLOC))
goto force;
- if (unlikely(task_in_memcg_oom(current)))
- goto nomem;
-
- if (!gfpflags_allow_blocking(gfp_mask))
- goto nomem;
-
- /*
- * OOM victim still needs to charge memory to exit. OOM reaper should
- * help but it might fail on mmap_lock contention. If the victim is a
- * large thread group then all exiting threads might compete on oom_lock
- * just to learn that there is nothing really killable anymore. Bail
- * out early and fail the charge to expedite their exit. They are
- * considered fully reclaimed by the oom reaper and they shouldn't
- * contribute further charges.
- */
- if (tsk_is_oom_victim(current) &&
- mm_flags_test(MMF_OOM_SKIP, current->signal->oom_mm))
+ if (!memcg_charge_may_reclaim(gfp_mask))
goto nomem;
- __memcg_memory_event(mem_over_limit, MEMCG_MAX, allow_spinning);
+ nr_reclaimed = memcg_charge_reclaim(mem_over_limit, nr_pages, gfp_mask,
+ reclaim_options);
raised_max_event = true;
- psi_memstall_enter(&pflags);
- nr_reclaimed = try_to_free_mem_cgroup_pages(mem_over_limit, nr_pages,
- gfp_mask, reclaim_options, NULL);
- psi_memstall_leave(&pflags);
-
if (mem_cgroup_margin(mem_over_limit) >= nr_pages)
goto retry;
--
2.52.0
next prev parent reply other threads:[~2026-10-03 0:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-03 0:15 [PATCH v1 0/3] mm/readahead: avoid per-folio memcg reclaim Joanne Koong
2026-10-03 0:15 ` Joanne Koong [this message]
2026-10-05 18:49 ` [PATCH v1 1/3] mm: memcontrol: factor reclaim logic out of try_charge_memcg() Rik van Riel
2026-10-03 0:15 ` [PATCH v1 2/3] mm: memcontrol: add mem_cgroup_reclaim_for_batch() Joanne Koong
2026-10-03 0:15 ` [PATCH v1 3/3] mm/readahead: avoid per-folio memcg reclaim Joanne Koong
2026-10-05 12:26 ` [PATCH v1 0/3] " Jan Kara
2026-10-06 14:01 ` Joanne Koong
2026-10-07 15:30 ` Jan Kara
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=20261003001555.3498357-2-joannelkoong@gmail.com \
--to=joannelkoong@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=liam@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=riel@surriel.com \
--cc=roman.gushchin@linux.dev \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--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 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.