linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: jglisse@redhat.com
To: linux-kernel@vger.kernel.org
Cc: "Jérôme Glisse" <jglisse@redhat.com>,
	linux-rdma@vger.kernel.org, "Jason Gunthorpe" <jgg@mellanox.com>,
	"Leon Romanovsky" <leonro@mellanox.com>,
	"Doug Ledford" <dledford@redhat.com>,
	"Artemy Kovalyov" <artemyko@mellanox.com>,
	"Moni Shoua" <monis@mellanox.com>,
	"Mike Marciniszyn" <mike.marciniszyn@intel.com>,
	"Kaike Wan" <kaike.wan@intel.com>,
	"Dennis Dalessandro" <dennis.dalessandro@intel.com>
Subject: [PATCH v4 0/1] Use HMM for ODP v4
Date: Thu, 11 Apr 2019 14:13:13 -0400	[thread overview]
Message-ID: <20190411181314.19465-1-jglisse@redhat.com> (raw)

From: Jérôme Glisse <jglisse@redhat.com>

Just fixed Kconfig and build when ODP was not enabled, other than that
this is the same as v3. Here is previous cover letter:

Git tree with all prerequisite:
https://cgit.freedesktop.org/~glisse/linux/log/?h=rdma-odp-hmm-v4

This patchset convert RDMA ODP to use HMM underneath this is motivated
by stronger code sharing for same feature (share virtual memory SVM or
Share Virtual Address SVA) and also stronger integration with mm code to
achieve that. It depends on HMM patchset posted for inclusion in 5.2 [2]
and [3].

It has been tested with pingpong test with -o and others flags to test
different size/features associated with ODP.

Moreover they are some features of HMM in the works like peer to peer
support, fast CPU page table snapshot, fast IOMMU mapping update ...
It will be easier for RDMA devices with ODP to leverage those if they
use HMM underneath.

Quick summary of what HMM is:
    HMM is a toolbox for device driver to implement software support for
    Share Virtual Memory (SVM). Not only it provides helpers to mirror a
    process address space on a device (hmm_mirror). It also provides
    helper to allow to use device memory to back regular valid virtual
    address of a process (any valid mmap that is not an mmap of a device
    or a DAX mapping). They are two kinds of device memory. Private memory
    that is not accessible to CPU because it does not have all the expected
    properties (this is for all PCIE devices) or public memory which can
    also be access by CPU without restriction (with OpenCAPI or CCIX or
    similar cache-coherent and atomic inter-connect).

    Device driver can use each of HMM tools separatly. You do not have to
    use all the tools it provides.

For RDMA device i do not expect a need to use the device memory support
of HMM. This device memory support is geared toward accelerator like GPU.


You can find a branch [1] with all the prerequisite in. This patch is on
top of rdma-next with the HMM patchset [2] and mmu notifier patchset [3]
applied on top of it.

[1] https://cgit.freedesktop.org/~glisse/linux/log/?h=rdma-odp-hmm-v4
[2] https://lkml.org/lkml/2019/4/3/1032
[3] https://lkml.org/lkml/2019/3/26/900

Cc: linux-rdma@vger.kernel.org
Cc: Jason Gunthorpe <jgg@mellanox.com>
Cc: Leon Romanovsky <leonro@mellanox.com>
Cc: Doug Ledford <dledford@redhat.com>
Cc: Artemy Kovalyov <artemyko@mellanox.com>
Cc: Moni Shoua <monis@mellanox.com>
Cc: Mike Marciniszyn <mike.marciniszyn@intel.com>
Cc: Kaike Wan <kaike.wan@intel.com>
Cc: Dennis Dalessandro <dennis.dalessandro@intel.com>

Jérôme Glisse (1):
  RDMA/odp: convert to use HMM for ODP v4

 drivers/infiniband/Kconfig         |   3 +-
 drivers/infiniband/core/umem_odp.c | 499 ++++++++---------------------
 drivers/infiniband/hw/mlx5/mem.c   |  20 +-
 drivers/infiniband/hw/mlx5/mr.c    |   2 +-
 drivers/infiniband/hw/mlx5/odp.c   | 106 +++---
 include/rdma/ib_umem_odp.h         |  49 ++-
 6 files changed, 231 insertions(+), 448 deletions(-)

-- 
2.20.1


             reply	other threads:[~2019-04-11 18:13 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-11 18:13 jglisse [this message]
2019-04-11 18:13 ` [PATCH v4 1/1] RDMA/odp: convert to use HMM for ODP v4 jglisse
2019-05-06 19:56 ` [PATCH v4 0/1] Use " Jason Gunthorpe
2019-05-21 20:53   ` Jerome Glisse
2019-05-22  0:52     ` Jason Gunthorpe
2019-05-22 17:48       ` Jerome Glisse
2019-05-22 18:32         ` Jason Gunthorpe
2019-05-22 19:22         ` Jason Gunthorpe
2019-05-22 21:49           ` Jerome Glisse
2019-05-22 22:43             ` Jason Gunthorpe
2019-05-22 20:12         ` Jason Gunthorpe
2019-05-22 21:12           ` Ralph Campbell
2019-05-22 22:06             ` Jerome Glisse
2019-05-22 22:04           ` Jerome Glisse
2019-05-22 22:39             ` Jason Gunthorpe
2019-05-22 22:42               ` Jerome Glisse
2019-05-22 22:52                 ` Jason Gunthorpe
2019-05-22 23:57         ` Jason Gunthorpe
2019-05-23 15:04           ` Jerome Glisse
2019-05-23 15:41             ` Jason Gunthorpe
2019-05-23 15:52               ` Jerome Glisse
2019-05-23 16:34                 ` Jason Gunthorpe
2019-05-23 17:33                   ` Jerome Glisse
2019-05-23 17:55                     ` Jason Gunthorpe
2019-05-23 18:24                       ` Jerome Glisse
2019-05-23 19:10                         ` Jason Gunthorpe
2019-05-23 19:39                           ` Jerome Glisse
2019-05-23 19:47                             ` Jason Gunthorpe
2019-05-24  6:40                           ` Christoph Hellwig
2019-05-24 12:44                             ` RFC: Run a dedicated hmm.git for 5.3 Jason Gunthorpe
2019-05-24 16:27                               ` Daniel Vetter
2019-05-24 16:53                                 ` Jason Gunthorpe
2019-05-24 16:59                                   ` Daniel Vetter
2019-05-25 22:52                               ` Andrew Morton
2019-05-27 19:12                                 ` Jason Gunthorpe
2019-06-06 15:25                                   ` Jason Gunthorpe
2019-06-06 19:53                                     ` Stephen Rothwell

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=20190411181314.19465-1-jglisse@redhat.com \
    --to=jglisse@redhat.com \
    --cc=artemyko@mellanox.com \
    --cc=dennis.dalessandro@intel.com \
    --cc=dledford@redhat.com \
    --cc=jgg@mellanox.com \
    --cc=kaike.wan@intel.com \
    --cc=leonro@mellanox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mike.marciniszyn@intel.com \
    --cc=monis@mellanox.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).