Re: [RFC PATCH 0/2] mm: swap: allow per-device skipping of zero-filled page check

[Kairui Song <ryncsn@gmail.com>]

On Mon, May 18, 2026 at 04:34:53PM +0800, Youngjun Park wrote:
> Currently, the swap layer checks whether a page is entirely zero-filled
> before writing it out to the swap device. However, some swap backends,
> such as zram and our custom swap device, already perform their own
> same-filled page checking internally. This results in redundant CPU operations 
> checking same page pattern.
> 
> This patchset introduces a new swapon flag, SWAP_FLAG_SKIP_ZERO_CHECK,
> to eliminate this redundancy. I introduce this as a per-device flag
> rather than a global setting because traditional swap devices still
> benefit from the swap layer's zero page check to avoid unnecessary I/O.
> By using this flag, userspace can selectively disable the zero check
> only for specific backends.
> 
> Furthermore, on certain architectures where the zero map is managed via
> a separate bitmap, skipping this check allows bypassing
> the bitmap allocation entirely (saving memory).
> 
> This modification is based on the previous discussion with Nhat Pham [1].
> Additionally, this patchset is built on top of Kairui Song's recent
> patchset regarding swap table and zeromap modifications [2].
> 
> Tested simply with zram on QEMU to verify zero-filled page handling.
> 
> References:
> [1] https://lore.kernel.org/linux-mm/acQvNRLpHwnHt7i+@yjaykim-PowerEdge-T330/
> [2] https://lore.kernel.org/linux-mm/20260517-swap-table-p4-v5-0-88ae43e064c7@tencent.com/T/#t
> 
> Youngjun Park (2):
>   mm: swap: add SWAP_FLAG_SKIP_ZERO_CHECK to skip zero-filled page check
>   mm: swap: do not allocate zero_bitmap if zero check is skipped
> 
>  include/linux/swap.h |  4 +++-
>  mm/page_io.c         |  7 ++++++-
>  mm/swap.h            | 12 ++++++++++++
>  mm/swapfile.c        | 14 ++++++++++----
>  4 files changed, 31 insertions(+), 6 deletions(-)
> 
> -- 
> 2.34.1
> 

Hi YoungJun,

I think this idea might be useful, some workloads with very few zero
folios doesn't benefit from this zero folio detection and it's more of a
burden than gain:

For example, one test result with MySQL:

pswpin      129323368
pswpout     131460192
swpin_zero       4641
swpout_zero    248210

Less than 0.3% percent of the pages are zero, and almost none of the
zero pages are swapped back.

I think the zero page detection is actually better combined with
compression, e.g. ZRAM & ZSWAP which will always have to touch the
content of the page. But some devices may be able to just accept
the folio as it is and CPU may not want or need to read the content
again before pass the folio to the device, that may save some CPU
time I think?

How we can make this zero check as an interface is arguable though.

So I think the user might not be limited to ZRAM.