From: Leon Romanovsky <leon@kernel.org>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Alistair Popple <apopple@nvidia.com>,
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: Sun, 2 Feb 2025 10:22:23 +0200 [thread overview]
Message-ID: <20250202082223.GA3359673@unreal> (raw)
In-Reply-To: <20250131145237.GQ5556@nvidia.com>
On Fri, Jan 31, 2025 at 10:52:37AM -0400, Jason Gunthorpe wrote:
> 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/
The latest proposal for LSF/MM 2025 is here:
[LSF/MM/BPF TOPIC] DMA mapping API in complex scenarios
https://lore.kernel.org/linux-rdma/20250122071600.GC10702@unreal/T/#u
Thanks
prev parent reply other threads:[~2025-02-02 8:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-31 2:59 [LSF/MM/BPF TOPIC] The future of ZONE_DEVICE pages 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
2025-02-02 8:22 ` Leon Romanovsky [this message]
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=20250202082223.GA3359673@unreal \
--to=leon@kernel.org \
--cc=apopple@nvidia.com \
--cc=balbirs@nvidia.com \
--cc=david@redhat.com \
--cc=jgg@nvidia.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 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.