From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: lsf-pc@lists.linux-foundation.org
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Matthew Wilcox <willy@infradead.org>,
Axel Rasmussen <axelrasmussen@google.com>,
Guru Anbalagane <gurua@google.com>, Wei Xu <weixugc@google.com>,
Yuanchu Xie <yuanchu@google.com>
Subject: [LSF/MM/BPF TOPIC] Physical LRU scanning feasibility
Date: Wed, 8 Jan 2025 21:46:31 +0000 [thread overview]
Message-ID: <83bebb7f-f157-4179-b7ec-b25b2ee4270d@lucifer.local> (raw)
Hi all,
Not too long ago I took some time to investigate the possibility of
scanning physical memory directly by traversing the memory map directly
rather than the LRU linked list.
This was inspired by a post from Matthew [0] wherein he demonstrated just
how significant the difference is between traversing arrays of contiguous
data on a modern system vs. the almost worst-case scenario of traversing a
linked-list.
I tested how this might look by implementing code which simply traverses
and filters the memory map for LRU pages, simplifying as much as possible.
However no matter which machine (ranging from 16 GB - 192 GB) or whether
virtualised or real hardware, I found unfortunately disappointing results -
the act of having to scan such a large range of memory resulted in
performance significantly less than a typical LRU scan at low memory
utilisation and performance at best matching LRU scanning at high memory
utilisation (simulating higher memory pressure).
There are a number of factors at play here, and perhaps the shrinkage of
struct page (allowing for denser placement in cache lines), or an improved
algorithm might lead to more promising results.
Having discussed this with Matthew, he suggested I put forward a proposal
to discuss this area in order that we can learn from this should it appear
this approach is unworkable or perhaps determine whether there might be
something to this that we might still salvage.
I intend to do some more research and generate some more specific numbers
(feel free to give feedback here) before LSF so we can have something more
specific to talk about.
I always envisioned this approach being somehow integrated with MGLRU and I
wonder if some hybrid means of integrating this approach with the MGLRU one
might make sense, which could also be another area of discussion.
Thanks!
[0]:https://lore.kernel.org/linux-mm/ZTc7SHQ4RbPkD3eZ@casper.infradead.org/
next reply other threads:[~2025-01-08 21:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-08 21:46 Lorenzo Stoakes [this message]
2025-01-08 22:33 ` Yosry Ahmed
2025-01-09 12:38 ` Lorenzo Stoakes
2025-02-22 19:12 ` Lorenzo Stoakes
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=83bebb7f-f157-4179-b7ec-b25b2ee4270d@lucifer.local \
--to=lorenzo.stoakes@oracle.com \
--cc=axelrasmussen@google.com \
--cc=gurua@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=yuanchu@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