linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Alistair Popple <apopple@nvidia.com>
Cc: linux-mm@kvack.org, lsf-pc@lists.linux-foundation.org,
	david@redhat.com, willy@infradead.org, ziy@nvidia.com,
	jhubbard@nvidia.com, balbirs@nvidia.com
Subject: Re: [LSF/MM/BPF TOPIC] The future of ZONE_DEVICE pages
Date: Fri, 31 Jan 2025 10:52:37 -0400	[thread overview]
Message-ID: <20250131145237.GQ5556@nvidia.com> (raw)
In-Reply-To: <ytwoxegtun3j2454zi4vybahqbvdhwmspq6eg2odvupqw2m2yr@cdbgu6sjfqze>

On Fri, Jan 31, 2025 at 01:59:09PM +1100, Alistair Popple wrote:
> Combining P2PDMA and DEVICE_PRIVATE pages
> =========================================
> 
> Currently device memory that cannot be directly accessed via the CPU can be
> represented by DEVICE_PRIVATE pages allowing it to be mapped and treated like
> a normal virtual page by userpsace. Many devices also support accessing device
> memory directly from the CPU via a PCIe BAR.
> 
> This access requires a P2PDMA page, meaning there are potentially two pages
> tracking the same piece of physical memory. This not only seems wasteful but
> fraught - for example device drivers need to keep page lifetimes in sync. I
> would like to discuss ways of solving this.

My general plan for this has been to teach the DMA API how to do P2P
without struct page. Leon's topic is the frist step on this journey.
  https://lore.kernel.org/linux-mm/97f385db-42c9-4c04-8fba-9b1ba8ffc525@nvidia.com/

When we can DMA map P2P memory without struct page then we can talk
about what API changes would be needed to take advantage of that.

However, merging P2P and DEVICE_PRIVATE seems very tricky to me, you'd
have to make the type of page dependent on how it was read out of the
PTE - a swap entry is PRIVATE, a normal PTE is P2P.

Further, a struct page is necessary if any P2P pages are being placed
into VMAs..

Jason


  parent reply	other threads:[~2025-01-31 14:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-31  2:59 Alistair Popple
2025-01-31  3:29 ` Balbir Singh
2025-01-31  3:58 ` Zi Yan
2025-01-31  5:50   ` Alistair Popple
2025-01-31 15:34     ` Zi Yan
2025-01-31  8:47 ` David Hildenbrand
2025-02-05 10:12   ` Alistair Popple
2025-01-31 14:52 ` Jason Gunthorpe [this message]
2025-02-02  8:22   ` Leon Romanovsky

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=20250131145237.GQ5556@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=apopple@nvidia.com \
    --cc=balbirs@nvidia.com \
    --cc=david@redhat.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox