From: Matthew Wilcox <willy@infradead.org>
To: Gregory Price <gregory.price@memverge.com>
Cc: Gregory Price <gourry.memverge@gmail.com>,
linux-mm@kvack.org, linux-api@vger.kernel.org,
linux-arch@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org, ying.huang@intel.com,
dan.j.williams@intel.com, honggyu.kim@sk.com, corbet@lwn.net,
arnd@arndb.de, luto@kernel.org, akpm@linux-foundation.org,
shuah@kernel.org
Subject: Re: [RFC v3 3/3] ktest: sys_move_phys_pages ktest
Date: Tue, 19 Mar 2024 18:38:23 +0000 [thread overview]
Message-ID: <Zfnbn8H4O9neZhcm@casper.infradead.org> (raw)
In-Reply-To: <ZfnaMa6x/O68ENsP@memverge.com>
On Tue, Mar 19, 2024 at 02:32:17PM -0400, Gregory Price wrote:
> On Tue, Mar 19, 2024 at 06:20:33PM +0000, Matthew Wilcox wrote:
> > On Tue, Mar 19, 2024 at 02:14:33PM -0400, Gregory Price wrote:
> > > On Tue, Mar 19, 2024 at 05:52:46PM +0000, Matthew Wilcox wrote:
> > > > On Tue, Mar 19, 2024 at 01:26:09PM -0400, Gregory Price wrote:
> > > > > Implement simple ktest that looks up the physical address via
> > > > > /proc/self/pagemap and migrates the page based on that information.
> > > >
> > > > What? LOL. No.
> > > >
> > >
> > > Certainly the test is stupid and requires admin, but I could not
> > > come up an easier test to demonstrate the concept - and the docs
> > > say to include a test with all syscall proposals.
> > >
> > > Am I missing something else important?
> > > (stupid question: of course I am, but alas I must ask it)
> >
> > It's not that the test is stupid. It's the concept that's stupid.
>
> Ok i'll bite.
>
> The 2 major ways page-hotness is detected right now is page-faults
> (induced or otherwise) and things like IBS/PEBS.
>
> page-faults cause overhead, and IBS/PEBS actually miss upwards of ~66%
> of all traffic (if you want the details i can dig up the presentation,
> but TL;DR: prefetcher traffic is missed entirely).
>
> so OCP folks have been proposing hotness-tracking offloaded to the
> memory devices themselves:
>
> https://www.opencompute.org/documents/ocp-cms-hotness-tracking-requirements-white-paper-pdf-1
>
> (it's come along further than this white paper, but i need to dig up
> the new information).
>
> These devices are incapable of providing virtual addressing information,
> and doing reverse lookups of addresses is inordinately expensive from
> user space. This leaves: Do it all in a kernel task, or give user space
> an an interface to operate on data provided by the device.
>
> The syscall design is mostly being posted right now to collaborate via
> public channels, but if the idea is so fundamentally offensive then i'll
> drop it and relay the opinion accordingly.
The syscall design is wrong. Exposing physical addresses to userspace
is never the right answer. Think rowhammer.
I'm vehemently opposed to all of the bullshit around CXL. However, if you
are going to propose something, it should be based around an abstraction.
Say "We have 8 pools of memory. This VMA is backed by memory from pools
3 & 6. The relative hotness of the 8 pools are <vector>. The quantities
of memory in the 8 ppols are <vector>". And then you can say "migrate
this range of memory to pool 2".
That's just an initial response to the idea. I refuse to invest a
serious amount of time in a dead-end idea like CXL memory pooling.
next prev parent reply other threads:[~2024-03-19 18:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-19 17:26 [RFC v3 0/3] move_phys_pages syscall - migrate page contents given Gregory Price
2024-03-19 17:26 ` [RFC v3 1/3] mm/migrate: refactor add_page_for_migration for code re-use Gregory Price
2024-03-19 17:26 ` [RFC v3 2/3] mm/migrate: Create move_phys_pages syscall Gregory Price
2024-03-19 17:26 ` [RFC v3 3/3] ktest: sys_move_phys_pages ktest Gregory Price
2024-03-19 17:52 ` Matthew Wilcox
2024-03-19 18:08 ` Matthew Wilcox
2024-03-19 18:16 ` [RFC v3 3/3] ktest: sys_move_phys_pages ktesty Gregory Price
2024-03-19 18:18 ` Gregory Price
2024-03-19 18:14 ` [RFC v3 3/3] ktest: sys_move_phys_pages ktest Gregory Price
2024-03-19 18:20 ` Matthew Wilcox
2024-03-19 18:32 ` Gregory Price
2024-03-19 18:38 ` Matthew Wilcox [this message]
2024-03-19 18:50 ` Gregory Price
2024-03-20 2:48 ` [RFC v3 0/3] move_phys_pages syscall - migrate page contents given Huang, Ying
2024-03-20 4:39 ` Gregory Price
2024-03-20 6:01 ` Huang, Ying
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=Zfnbn8H4O9neZhcm@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=gourry.memverge@gmail.com \
--cc=gregory.price@memverge.com \
--cc=honggyu.kim@sk.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=shuah@kernel.org \
--cc=ying.huang@intel.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;
as well as URLs for NNTP newsgroup(s).