From: Jordan Niethe <jniethe@nvidia.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-mm@kvack.org, balbirs@nvidia.com, matthew.brost@intel.com,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, david@redhat.com,
ziy@nvidia.com, apopple@nvidia.com, lorenzo.stoakes@oracle.com,
lyude@redhat.com, dakr@kernel.org, airlied@gmail.com,
simona@ffwll.ch, rcampbell@nvidia.com, mpenttil@redhat.com,
jgg@nvidia.com
Subject: Re: [RFC PATCH 0/6] Remove device private pages from physical address space
Date: Tue, 2 Dec 2025 12:31:34 +1100 [thread overview]
Message-ID: <0414eb13-77ae-4c41-b32f-3ae637e5da48@nvidia.com> (raw)
In-Reply-To: <aSm7NTtNfGcXbuwr@casper.infradead.org>
Hi,
On 29/11/25 02:09, Matthew Wilcox wrote:
> On Fri, Nov 28, 2025 at 03:41:40PM +1100, Jordan Niethe wrote:
>> A consequence of placing the device private pages outside of the
>> physical address space is that they no longer have a PFN. However, it is
>> still necessary to be able to look up a corresponding device private
>> page from a device private PTE entry, which means that we still require
>> some way to index into this device private address space. This leads to
>> the idea of a device private PFN. This is like a PFN but instead of
>
> Don't call it a "device private PFN". That's going to lead to
> confusion. Device private index? Device memory index?
Sure, I think 'device memory index' is fine. What I was trying to
express with 'device private PFN' here is that each index into device
memory still represents a PAGE_SIZE region, but I agree it leads to
further confusion.
Thanks,
Jordan.
>
>> By removing the device private pages from the physical address space,
>> this RFC also opens up the possibility to moving away from tracking
>> device private memory using struct pages in the future. This is
>> desirable as on systems with large amounts of memory these device
>> private struct pages use a signifiant amount of memory and take a
>> significant amount of time to initialize.
>
> I did tell Jerome he was making a huge mistake with his design, but
> he forced it in anyway.
next prev parent reply other threads:[~2025-12-02 1:31 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-28 4:41 [RFC PATCH 0/6] Remove device private pages from physical address space Jordan Niethe
2025-11-28 4:41 ` [RFC PATCH 1/6] mm/hmm: Add flag to track device private PFNs Jordan Niethe
2025-11-28 18:36 ` Matthew Brost
2025-12-02 1:20 ` Jordan Niethe
2025-12-03 4:25 ` Balbir Singh
2025-11-28 4:41 ` [RFC PATCH 2/6] mm/migrate_device: Add migrate PFN " Jordan Niethe
2025-11-28 4:41 ` [RFC PATCH 3/6] mm/page_vma_mapped: Add flags to page_vma_mapped_walk::pfn " Jordan Niethe
2025-11-28 4:41 ` [RFC PATCH 4/6] mm: Add a new swap type for migration entries with " Jordan Niethe
2025-12-01 2:43 ` Chih-En Lin
2025-12-02 1:42 ` Jordan Niethe
2025-11-28 4:41 ` [RFC PATCH 5/6] mm/util: Add flag to track device private PFNs in page snapshots Jordan Niethe
2025-11-28 4:41 ` [RFC PATCH 6/6] mm: Remove device private pages from the physical address space Jordan Niethe
2025-11-28 6:52 ` kernel test robot
2025-11-28 17:51 ` Jason Gunthorpe
2025-12-02 2:28 ` Jordan Niethe
2025-12-02 4:10 ` Alistair Popple
2025-11-30 5:45 ` kernel test robot
2025-11-28 7:40 ` [RFC PATCH 0/6] Remove device private pages from " David Hildenbrand (Red Hat)
2025-11-30 23:33 ` Alistair Popple
2025-11-28 15:09 ` Matthew Wilcox
2025-12-02 1:31 ` Jordan Niethe [this message]
2025-11-28 16:07 ` Mika Penttilä
2025-12-02 1:32 ` Jordan Niethe
2025-11-28 19:22 ` Matthew Brost
2025-11-30 23:23 ` Alistair Popple
2025-12-01 1:51 ` Matthew Brost
2025-12-02 1:40 ` Jordan Niethe
2025-12-02 22:20 ` Balbir Singh
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=0414eb13-77ae-4c41-b32f-3ae637e5da48@nvidia.com \
--to=jniethe@nvidia.com \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=balbirs@nvidia.com \
--cc=dakr@kernel.org \
--cc=david@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jgg@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=lyude@redhat.com \
--cc=matthew.brost@intel.com \
--cc=mpenttil@redhat.com \
--cc=rcampbell@nvidia.com \
--cc=simona@ffwll.ch \
--cc=willy@infradead.org \
--cc=ziy@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.