mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

             reply	other threads:[~2026-09-04  3:54 UTC|newest]

Thread overview: 6+ 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-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®