From: Johannes Weiner <hannes@cmpxchg.org>
To: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Brendan Jackman <jackmanb@google.com>, Zi Yan <ziy@nvidia.com>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Mike Rapoport <rppt@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] mm: fix reclaim storms in defrag_mode
Date: Thu, 9 Jul 2026 13:51:19 -0400 [thread overview]
Message-ID: <ak_fl7Nq0DHmQd2K@cmpxchg.org> (raw)
In-Reply-To: <akWwg0irlanA_y1i@linux.dev>
On Wed, Jul 01, 2026 at 05:31:11PM -0700, Shakeel Butt wrote:
> On Fri, Jun 26, 2026 at 02:21:16PM -0400, Johannes Weiner wrote:
> > As we deployed vm.defrag_mode=1 into Meta production, some workloads
> > regressed with recurring pressure spikes and swap storms (which in turn
> > triggered userspace OOM rules on pressure and swap utilization levels).
> >
> > Tracing pinned this to non-movable
>
> allocation?
>
> > requests spinning and reclaiming
^^^
non-movable requests :)
> > unproductively when kswapd/kcompactd are overwhelmed. Direct reclaim
> > predominantly frees up pages in movable blocks, but those requests
> > cannot use that space under defrag_mode rules;
>
> Do we have these rules documented somewhere?
Kind of. The crux is that defrag_mode enforces ALLOC_NOFRAGMENT in the
slowpath as well (whereas vanilla just does it in the fastpath). So
it's documented to the extent that ALLOC_NOFRAGMENT is.
> > and it is unlikely to
> > free up whole blocks incidentally for __rmqueue_claim() to work.
> >
> > This series fixes it by making non-movable requests participate in
> > pageblock production in the allocator slowpath.
>
> Sorry after reading above sentence I didn't get what those allocators will do
> things differently after the series (I still have to go through the series).
Let me add:
[...] - meaning, they will invoke direct reclaim and direct compaction
with pageblock_order.
Does that clarify it a bit?
prev parent reply other threads:[~2026-07-09 17:51 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-26 18:21 [PATCH 0/4] mm: fix reclaim storms in defrag_mode Johannes Weiner
2026-06-26 18:21 ` [PATCH 1/4] mm: page_alloc: __GFP_FS lockdep annotation for direct compaction Johannes Weiner
2026-07-01 13:45 ` Vlastimil Babka (SUSE)
2026-07-02 0:39 ` Shakeel Butt
2026-06-26 18:21 ` [PATCH 2/4] mm: compaction: support non-movable compaction for pageblock requests Johannes Weiner
2026-07-01 14:19 ` Vlastimil Babka (SUSE)
2026-07-01 15:28 ` Johannes Weiner
2026-07-01 18:14 ` Vlastimil Babka (SUSE)
2026-07-01 21:11 ` Johannes Weiner
2026-07-02 9:28 ` Vlastimil Babka (SUSE)
2026-07-09 17:39 ` Johannes Weiner
2026-07-09 20:42 ` Vlastimil Babka (SUSE)
2026-07-02 1:47 ` Zi Yan
2026-07-09 17:42 ` Johannes Weiner
2026-06-26 18:21 ` [PATCH 3/4] mm: page_alloc: move capture_control to the page allocator Johannes Weiner
2026-07-01 18:02 ` Vlastimil Babka (SUSE)
2026-07-01 20:57 ` Johannes Weiner
2026-07-02 10:20 ` Vlastimil Babka (SUSE)
2026-07-09 17:45 ` Johannes Weiner
2026-07-09 20:44 ` Vlastimil Babka (SUSE)
2026-06-26 18:21 ` [PATCH 4/4] mm: page_alloc: fix non-movable reclaim storm in defrag_mode Johannes Weiner
2026-06-26 18:29 ` Zi Yan
2026-06-26 18:43 ` Johannes Weiner
2026-07-01 18:06 ` Vlastimil Babka (SUSE)
2026-07-01 21:02 ` Johannes Weiner
2026-07-02 0:31 ` [PATCH 0/4] mm: fix reclaim storms " Shakeel Butt
2026-07-09 17:51 ` Johannes Weiner [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=ak_fl7Nq0DHmQd2K@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=jackmanb@google.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--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.