linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@mellanox.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org,
	linux-pci@vger.kernel.org, linux-rdma@vger.kernel.org,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Logan Gunthorpe" <logang@deltatee.com>,
	"Stephen Bates" <sbates@raithlin.com>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"Ira Weiny" <iweiny@intel.com>, "Christoph Hellwig" <hch@lst.de>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Ralph Campbell" <rcampbell@nvidia.com>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Don Dutile" <ddutile@redhat.com>
Subject: Re: [LSF/MM TOPIC] get_user_pages() for PCI BAR Memory
Date: Sat, 8 Feb 2020 09:54:05 -0400	[thread overview]
Message-ID: <20200208135405.GO23346@mellanox.com> (raw)
In-Reply-To: <20e3149e-4240-13e7-d16e-3975cfbe4d38@amd.com>

On Sat, Feb 08, 2020 at 02:10:59PM +0100, Christian König wrote:
> > For patch sets, we've seen a number of attempts so far, but little has
> > been merged yet. Common elements of past discussions have been:
> >   - Building struct page for BAR memory
> >   - Stuffing BAR memory into scatter/gather lists, bios and skbs
> >   - DMA mapping BAR memory
> >   - Referencing BAR memory without a struct page
> >   - Managing lifetime of BAR memory across multiple drivers
> 
> I can only repeat Jérôme that this most likely will never work correctly
> with get_user_pages().

I suppose I'm using 'get_user_pages()' as something of a placeholder
here to refer to the existing family of kernel DMA consumers that call
get_user_pages to work on VMA backed process visible memory.

We have to have something like get_user_pages() because the kernel
call-sites are fundamentally only dealing with userspace VA. That is
how their uAPIs are designed, and we want to keep them working.

So, if something doesn't fit into get_user_pages(), ie because it
doesn't have a VMA in the first place, then that is some other
discussion. DMA buf seems like a pretty good answer.

> E.g. you have memory which is not even CPU addressable, but can be shared
> between GPUs using XGMI, NVLink, SLI etc....

For this kind of memory if it is mapped into a VMA with
DEVICE_PRIVATE, as Jerome has imagined, then it would be part of this
discussion.

> So we need to figure out how express DMA addresses outside of the CPU
> address space first before we can even think about something like extending
> get_user_pages() for P2P in an HMM scenario.

Why? This is discussion is not exclusively for GPU. We have many use
cases that do not have CPU invisible memory to worry about, and I
don't think defining how DMA mapping works for cpu-invisible
interconnect overlaps with figuring out how to make get_user_pages
work with existing ZONE_DEVICE memory types.

ie the challenge here is how to deliver the required information to
the p2pdma subsystem so a get_user_pages() call site can do a DMA map.

Improving the p2pdma subsystem to handle more complex cases like CPU
invisible memory and interconnect is a different topic, I think :)

Regards,
Jason


  reply	other threads:[~2020-02-08 13:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-07 18:24 [LSF/MM TOPIC] get_user_pages() for PCI BAR Memory Jason Gunthorpe
2020-02-07 19:46 ` Matthew Wilcox
2020-02-07 20:13   ` Jason Gunthorpe
2020-02-07 20:42     ` Matthew Wilcox
2020-02-14 10:35       ` Michal Hocko
2020-02-08 13:10 ` Christian König
2020-02-08 13:54   ` Jason Gunthorpe [this message]
2020-02-08 16:38     ` Christian König
2020-02-08 17:43       ` Jason Gunthorpe
2020-02-10 18:39         ` Logan Gunthorpe

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=20200208135405.GO23346@mellanox.com \
    --to=jgg@mellanox.com \
    --cc=christian.koenig@amd.com \
    --cc=dan.j.williams@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=ddutile@redhat.com \
    --cc=hch@lst.de \
    --cc=iweiny@intel.com \
    --cc=jglisse@redhat.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-mm@kvack.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=logang@deltatee.com \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=rcampbell@nvidia.com \
    --cc=sbates@raithlin.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).