From: Matthew Wilcox <willy@infradead.org>
To: Yosry Ahmed <yosryahmed@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Usama Arif <usamaarif642@gmail.com>,
akpm@linux-foundation.org, nphamcs@gmail.com,
chengming.zhou@linux.dev, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, kernel-team@meta.com,
Hugh Dickins <hughd@google.com>,
Huang Ying <ying.huang@intel.com>
Subject: Re: [PATCH 1/2] mm: store zero pages to be swapped out in a bitmap
Date: Thu, 30 May 2024 21:04:16 +0100 [thread overview]
Message-ID: <ZljbwMj-FNw9TqDV@casper.infradead.org> (raw)
In-Reply-To: <CAJD7tkYcTV_GOZV3qR6uxgFEvYXw1rP-h7WQjDnsdwM=g9cpAw@mail.gmail.com>
On Thu, May 30, 2024 at 09:24:20AM -0700, Yosry Ahmed wrote:
> I am wondering if it's even possible to take this one step further and
> avoid reclaiming zero-filled pages in the first place. Can we just
> unmap them and let the first read fault allocate a zero'd page like
> uninitialized memory, or point them at the zero page and make them
> read-only, or something? Then we could free them directly without
> going into the swap code to begin with.
I was having similar thoughts. You can see in do_anonymous_page() that
we simply map the shared zero page when we take a read fault on
unallocated anon memory.
So my question is where are all these zero pages coming from in the Meta
fleet? Obviously we never try to swap out the shared zero page (it's
not on any LRU list). So I see three possibilities:
- Userspace wrote to it, but it wrote zeroes. Then we did a memcmp(),
discovered it was zeroes and fall into this path. It would be safe
to just discard this page.
- We allocated it as part of a THP. We never wrote to this particular
page of the THP, so it's zero-filled. While it's safe to just
discard this page, we might want to write it for better swap-in
performance.
- Userspace wrote non-zeroes to it, then wrote zeroes to it before
abandoning use of this page, and so it eventually got swapped out.
Perhaps we could teach userspace to MADV_DONTNEED the page instead?
Has any data been gathered on this? Maybe there are other sources of
zeroed pages that I'm missing. I do remember a presentation at LSFMM
in 2022 from Google about very sparsely used THPs.
next prev parent reply other threads:[~2024-05-30 20:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-30 10:19 [PATCH 0/2] " Usama Arif
2024-05-30 10:19 ` [PATCH 1/2] " Usama Arif
2024-05-30 12:27 ` Johannes Weiner
2024-05-30 16:24 ` Yosry Ahmed
2024-05-30 19:18 ` Nhat Pham
2024-05-30 19:49 ` Yosry Ahmed
2024-05-30 20:04 ` Matthew Wilcox [this message]
2024-05-30 20:16 ` Yosry Ahmed
2024-05-31 18:18 ` Usama Arif
2024-05-30 16:20 ` Yosry Ahmed
2024-05-30 19:58 ` Andrew Morton
2024-05-30 10:19 ` [PATCH 2/2] mm: remove code to handle same filled pages Usama Arif
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=ZljbwMj-FNw9TqDV@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=chengming.zhou@linux.dev \
--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=usamaarif642@gmail.com \
--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