The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Altan Hacigumus <ahacigu.linux@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@kernel.org>,
	Kairui Song <kasong@tencent.com>, Qi Zheng <qi.zheng@linux.dev>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Barry Song <baohua@kernel.org>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
	Lorenzo Stoakes <ljs@kernel.org>,
	"Liam R . Howlett" <liam@infradead.org>,
	Vlastimil Babka <vbabka@kernel.org>,
	Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>,
	Jiayuan Chen <jiayuan.chen@shopee.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm/vmscan: clear hopeless kswapd when global direct reclaim makes progress
Date: Mon, 13 Jul 2026 07:20:01 -0400	[thread overview]
Message-ID: <20260713112001.GE276793@cmpxchg.org> (raw)
In-Reply-To: <20260711043946.68421-1-ahacigu.linux@gmail.com>

On Fri, Jul 10, 2026 at 09:39:46PM -0700, Altan Hacigumus wrote:
> Direct reclaim clears the hopeless kswapd state only once the node
> becomes balanced - added by commit dc9fe9b7056a ("mm/vmscan: mitigate
> spurious kswapd_failures reset from direct reclaim") so that cgroup
> memory.high reclaim cannot repeatedly revive a kswapd that is unable to
> balance the node. Before it, any reclaim progress revived kswapd.
> 
> However, this restriction also prevents global direct reclaim from
> reviving kswapd. Under sustained memory pressure, global direct reclaim
> may continue making progress without the node ever reaching the high
> watermark, leaving reclaim to allocating tasks.
> 
> The effect is visible on systems where a database workload mlocks most
> of memory and the remainder is under continuous pressure: allocations
> stall long enough that ordinary tasks (e.g. ssh) become slow or
> unresponsive, while kswapd sits idle.
> 
> Unlike memcg reclaim, global direct reclaim follows the same node-wide
> reclaim path as kswapd. Clear the hopeless state when global direct
> reclaim makes progress, while continuing to require a balanced node for
> memcg reclaim. kswapd_try_clear_hopeless() becomes static since struct
> scan_control is private to vmscan.c.
> 
> On a workload with most memory mlocked and the remainder under sustained
> churn, with swap enabled, comparing the same 60s window:
>                               base       patched
>   allocstall (all zones)    413441          6532
>   pgsteal_direct          15889552        255619
>   pgsteal_kswapd                 0      26079382
>   PSI memory full avg60     13.10%         9.37%
> 
> Direct reclaim was already reclaiming many pages in the baseline;
> this change lets kswapd resume doing that work asynchronously.

But does kswapd actually stop?

I don't see how you avoid re-introducing the issue described in
dc9fe9b7056a. Direct reclaim picking up a few pages is no guarantee
that kswapd is able to restore the watermarks and stop running.

The distinction between global reclaim and memcg reclaim seems
handwavy to me. Either can free a couple of pages on the node. Who is
doing it has little bearing on the question whether kswapd can balance
the node and go to sleep?

      reply	other threads:[~2026-07-13 11:20 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-11  4:39 [PATCH v2] mm/vmscan: clear hopeless kswapd when global direct reclaim makes progress Altan Hacigumus
2026-07-13 11:20 ` 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=20260713112001.GE276793@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=ahacigu.linux@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=baohua@kernel.org \
    --cc=david@kernel.org \
    --cc=jiayuan.chen@shopee.com \
    --cc=kasong@tencent.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=qi.zheng@linux.dev \
    --cc=rppt@kernel.org \
    --cc=shakeel.butt@linux.dev \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    --cc=weixugc@google.com \
    --cc=yuanchu@google.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