From: Usama Arif <usamaarif642@gmail.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: akpm@linux-foundation.org, hannes@cmpxchg.org,
shakeel.butt@linux.dev, david@redhat.com, ying.huang@intel.com,
hughd@google.com, willy@infradead.org, yosryahmed@google.com,
nphamcs@gmail.com, chengming.zhou@linux.dev, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, kernel-team@meta.com
Subject: Re: [PATCH v5 1/2] mm: store zero pages to be swapped out in a bitmap
Date: Fri, 14 Jun 2024 16:02:37 +0100 [thread overview]
Message-ID: <ced7a67e-8db9-4422-889e-76ee4958a622@gmail.com> (raw)
In-Reply-To: <87ed8zmvla.fsf@linux.intel.com>
On 14/06/2024 15:45, Andi Kleen wrote:
> Usama Arif <usamaarif642@gmail.com> writes:
>
>> Approximately 10-20% of pages to be swapped out are zero pages [1].
>> Rather than reading/writing these pages to flash resulting
>> in increased I/O and flash wear, a bitmap can be used to mark these
>> pages as zero at write time, and the pages can be filled at
>> read time if the bit corresponding to the page is set.
>> With this patch, NVMe writes in Meta server fleet decreased
>> by almost 10% with conventional swap setup (zswap disabled).
>>
>> [1] https://lore.kernel.org/all/20171018104832epcms5p1b2232e2236258de3d03d1344dde9fce0@epcms5p1/
> But how much did the CPU time increase? Surely the new loop is not free?
>
> -Andi
It is negligible.
For a zero filled page, without zero-fill optimization, the CPU would
have to do page compression in zswap or dispatch write to disk, so this
optimization is just replacing the CPU usage for these tasks with CPU
usage for checking if page is zero-filled. This is the reason why
same-filled optimization was there in zswap. Zswap should focus on
actual compression and this series is just moving the optimization to swap.
For a non-zero filled page, the loop quits the first instance you see
non zero data and checks the last word first, so its likely going to
quite very early on in the loop.
next prev parent reply other threads:[~2024-06-14 15:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-14 10:07 [PATCH v5 0/2] " Usama Arif
2024-06-14 10:07 ` [PATCH v5 1/2] " Usama Arif
2024-06-14 12:05 ` Chengming Zhou
2024-06-14 18:41 ` Yosry Ahmed
2024-06-14 14:45 ` Andi Kleen
2024-06-14 15:02 ` Usama Arif [this message]
2024-06-14 18:36 ` Yosry Ahmed
2024-06-14 20:23 ` Nhat Pham
2024-06-14 10:07 ` [PATCH v5 2/2] mm: remove code to handle same filled pages Usama Arif
2024-06-14 12:07 ` Chengming Zhou
2024-06-14 18:41 ` Yosry Ahmed
2024-06-14 20:25 ` Nhat Pham
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=ced7a67e-8db9-4422-889e-76ee4958a622@gmail.com \
--to=usamaarif642@gmail.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=chengming.zhou@linux.dev \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nphamcs@gmail.com \
--cc=shakeel.butt@linux.dev \
--cc=willy@infradead.org \
--cc=ying.huang@intel.com \
--cc=yosryahmed@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