From: Qinyun Tan <qinyuntan@linux.alibaba.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>, Zi Yan <ziy@nvidia.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Xunlei Pang <xlpang@linux.alibaba.com>,
"Liam R . Howlett" <liam@infradead.org>,
Nico Pache <nico.pache@linux.dev>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>, Lance Yang <lance.yang@linux.dev>,
Usama Arif <usama.arif@linux.dev>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Chris Down <chris@chrisdown.name>,
Chuanhua Han <hanchuanhua@oppo.com>,
Kairui Song <kasong@tencent.com>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org,
Qinyun Tan <qinyuntan@linux.alibaba.com>
Subject: [PATCH 0/2] mm: memcg: settle memory.high debt for non-blocking THP charges
Date: Fri, 4 Sep 2026 11:54:05 +0800 [thread overview]
Message-ID: <20260904035407.4098627-1-qinyuntan@linux.alibaba.com> (raw)
memory.high is enforced at two points after a charge succeeds: on
return to userspace, and synchronously in try_charge_memcg() for
large overcharges, the latter gated on gfpflags_allow_blocking().
THP charge paths pass the physical allocation gfp from
vma_thp_gfp_mask() to the memcg charge. With the default
defrag=madvise (and no MADV_HUGEPAGE), as well as with defrag=defer,
that gfp does not allow blocking. This is the right allocation
policy -- a THP is not worth direct compaction, fall back to smaller
orders instead -- but the charge code also reads it as "this context
cannot sleep" and skips the synchronous enforcement, even though
fault context sleeps just fine. Inside a single-syscall populate
loop (mlock(), MADV_POPULATE_*, any GUP-driven population) the
return-to-userspace hook is not reached between faults either, so
nothing throttles at all: a memcg's usage runs from memory.high
straight up to memory.max with zero reclaim and zero penalty sleep,
consuming the reaction window that userspace OOM handlers (oomd,
Kubernetes) depend on.
Patch 1 fixes the anonymous THP/mTHP fault path. The pre-existing
selftest test_memcg_high_sync readily reproduces the problem: with
transparent_hugepage/enabled=always it fails without the patch and
passes with it.
Patch 2 fixes the same problem for large folio swapin on
SWP_SYNCHRONOUS_IO devices (zram) with mTHP swapin enabled. Its
changelog carries measured before/after numbers for both the
reclaim-keeps-up regime and the penalty-sleep regime.
In both patches the charge gfp deliberately stays coupled to the
allocation gfp, so the fail-fast fallback at memory.max is fully
preserved; the over-high debt is instead settled from the fault
path, which knows its context can sleep.
A note for stable backports: mem_cgroup_handle_over_high() only
gained its gfp_mask argument in v6.6, from commit 9ea9cb00a82b ("mm:
memcontrol: fix GFP_NOFS recursion in memory.high enforcement");
older kernels take no argument. On kernels predating the swap table
rework the swapin charge sits in alloc_swap_folio() rather than
__swap_cache_alloc(), but patch 2's fix location at the end of
do_swap_page() applies unchanged.
Qinyun Tan (2):
mm: memcg: settle memory.high debt after THP faults with
non-blocking gfp
mm: memcg: settle memory.high debt after large folio swapin
mm/huge_memory.c | 8 ++++++++
mm/memory.c | 10 ++++++++++
2 files changed, 18 insertions(+)
--
2.55.0
next reply other threads:[~2026-09-04 3:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 3:54 Qinyun Tan [this message]
2026-09-04 3:54 ` [PATCH 1/2] mm: memcg: settle memory.high debt after THP faults with non-blocking gfp Qinyun Tan
2026-09-04 6:50 ` Baolin Wang
2026-09-04 9:05 ` Qinyun Tan
2026-09-04 15:10 ` Zi Yan
2026-09-11 3:19 ` Qinyun Tan
2026-09-04 3:54 ` [PATCH 2/2] mm: memcg: settle memory.high debt after large folio swapin Qinyun Tan
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=20260904035407.4098627-1-qinyuntan@linux.alibaba.com \
--to=qinyuntan@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=cgroups@vger.kernel.org \
--cc=chris@chrisdown.name \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=hanchuanhua@oppo.com \
--cc=hannes@cmpxchg.org \
--cc=kasong@tencent.com \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=nico.pache@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=xlpang@linux.alibaba.com \
--cc=ziy@nvidia.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.