Re: [PATCH mm-next] mm/swap: free swap cache folios the zap path gave up on

From: Jiayuan Chen

Date: Thu Oct 15 2026 - 21:22:07 EST


Hi Nhat


On 10/16/26 1:11 AM, Nhat Pham wrote:
On Wed, Oct 14, 2026 at 2:08 AM Jiayuan Chen <jiayuan.chen@xxxxxxxxx> wrote:
From: Jiayuan Chen <jiayuan.chen@xxxxxxxxxx>

On our production hosts we saw swap cache only pages keep growing for days:
on a box with a 500 GiB swap partition, 250 GiB of RAM and 250 GiB of
swap slots were held by folios that no process mapped any more, charged
That's a really nasty situation.

to cgroups whose workloads had long exited. The only way to get them
back was swapoff, and with other services actively swapping on the
same host that is not an option.
Is it not similar to cold file caches?


Not quite. A cold file cache can still be hit later. These folios
can't: no page table holds the swap entry any more, so nothing will
ever look them up again. They also hold swap slots, not just RAM, and
the allocator skips those slots until swap is half full.


The recommendation for these kind of scenarios (for both file and
anon) is to adopt a proactive reclaimer (in the same vein as senpai).
That's what we do internally.


Proactive reclaim does free them, but it works around the leak rather
than fixing it. In our case they were charged to cgroups that had
already been removed, so there was no cgroup left to reclaim from, and
reclaiming from the parent pushed out live anon first



Cc: Jiayuan Chen <jiayuan.chen@xxxxxxxxx>
Signed-off-by: Jiayuan Chen <jiayuan.chen@xxxxxxxxxx>
Code looks solid to me otherwise. Maybe include some numbers from your
testing in the cover letter to verify that the swap cache usage drop.


Thanks, will do in next version.