Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Usama Arif <usama.arif@linux.dev>
To: Youngjun Park <youngjun.park@lge.com>
Cc: Usama Arif <usama.arif@linux.dev>,
	linux-mm@kvack.org, akpm@linux-foundation.org, chrisl@kernel.org,
	kasong@tencent.com, shikemeng@huaweicloud.com, nphamcs@gmail.com,
	bhe@redhat.com, baohua@kernel.org
Subject: Re: [RFC PATCH 0/2] mm: swap: allow per-device skipping of zero-filled page check
Date: Tue, 19 May 2026 03:16:14 -0700	[thread overview]
Message-ID: <20260519101615.2876646-1-usama.arif@linux.dev> (raw)
In-Reply-To: <20260518073455.2495934-1-youngjun.park@lge.com>

On Mon, 18 May 2026 16:34:53 +0900 Youngjun Park <youngjun.park@lge.com> 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.

Hello!

So IMO, we should go in the other direction and remove same-filled page
support from zram. When we added zero-filled support to swap, we removed
it from zswap, because its not worth the extra overhead of maintaining
this in zswap.

I did some analysis at that time, and I remember more than 90% of the
same-filled pages on server workloads were zero-filled. I think someone
else did analysis on android (maybe Barry?) and it was about 85%.

IMO we should just remove same-filled page support from zram, and keep
this centralized in swap, so that everyone benefits.


> 
> 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
> 
> 


  parent reply	other threads:[~2026-05-19 10:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-18  7:34 [RFC PATCH 0/2] mm: swap: allow per-device skipping of zero-filled page check Youngjun Park
2026-05-18  7:34 ` [RFC PATCH 1/2] mm: swap: add SWAP_FLAG_SKIP_ZERO_CHECK to skip " Youngjun Park
2026-05-19  6:30   ` Christoph Hellwig
2026-05-19  7:08     ` YoungJun Park
2026-05-19  9:18       ` Christoph Hellwig
2026-05-21  6:46         ` YoungJun Park
2026-05-18  7:34 ` [RFC PATCH 2/2] mm: swap: do not allocate zero_bitmap if zero check is skipped Youngjun Park
2026-05-19 10:16 ` Usama Arif [this message]
2026-05-21  6:57   ` [RFC PATCH 0/2] mm: swap: allow per-device skipping of zero-filled page check YoungJun Park
2026-05-31 18:48 ` Kairui Song
2026-06-01  2:05   ` YoungJun Park

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=20260519101615.2876646-1-usama.arif@linux.dev \
    --to=usama.arif@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=bhe@redhat.com \
    --cc=chrisl@kernel.org \
    --cc=kasong@tencent.com \
    --cc=linux-mm@kvack.org \
    --cc=nphamcs@gmail.com \
    --cc=shikemeng@huaweicloud.com \
    --cc=youngjun.park@lge.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