All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: "John Hubbard" <jhubbard@nvidia.com>,
	"Jérôme Glisse" <jglisse@redhat.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [HMM v13 00/18] HMM (Heterogeneous Memory Management) v13
Date: Sat, 19 Nov 2016 20:20:35 +0530	[thread overview]
Message-ID: <8760njmslg.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.LNX.2.20.1611181638370.53648@blueforge.nvidia.com>

John Hubbard <jhubbard@nvidia.com> writes:

> On Fri, 18 Nov 2016, Jérôme Glisse wrote:
>
>> Cliff note: HMM offers 2 things (each standing on its own). First
>> it allows to use device memory transparently inside any process
>> without any modifications to process program code. Second it allows
>> to mirror process address space on a device.
>> 
>> Change since v12 is the use of struct page for device memory even if
>> the device memory is not accessible by the CPU (because of limitation
>> impose by the bus between the CPU and the device).
>> 
>> Using struct page means that their are minimal changes to core mm
>> code. HMM build on top of ZONE_DEVICE to provide struct page, it
>> adds new features to ZONE_DEVICE. The first 7 patches implement
>> those changes.
>> 
>> Rest of patchset is divided into 3 features that can each be use
>> independently from one another. First is the process address space
>> mirroring (patch 9 to 13), this allow to snapshot CPU page table
>> and to keep the device page table synchronize with the CPU one.
>> 
>> Second is a new memory migration helper which allow migration of
>> a range of virtual address of a process. This memory migration
>> also allow device to use their own DMA engine to perform the copy
>> between the source memory and destination memory. This can be
>> usefull even outside HMM context in many usecase.
>> 
>> Third part of the patchset (patch 17-18) is a set of helper to
>> register a ZONE_DEVICE node and manage it. It is meant as a
>> convenient helper so that device drivers do not each have to
>> reimplement over and over the same boiler plate code.
>> 
>> 
>> I am hoping that this can now be consider for inclusion upstream.
>> Bottom line is that without HMM we can not support some of the new
>> hardware features on x86 PCIE. I do believe we need some solution
>> to support those features or we won't be able to use such hardware
>> in standard like C++17, OpenCL 3.0 and others.
>> 
>> I have been working with NVidia to bring up this feature on their
>> Pascal GPU. There are real hardware that you can buy today that
>> could benefit from HMM. We also intend to leverage this inside the
>> open source nouveau driver.
>> 
>
> Hi,
>
> We (NVIDIA engineering) have been working closely with Jerome on this for 
> several years now, and I wanted to mention that NVIDIA is committed to 
> using HMM. We've done initial testing of this patchset on Pascal GPUs (a 
> bit more detail below) and it is looking good.
>   

This can also be used on IBM platforms like Minsky (
http://www.tomshardware.com/news/ibm-power8-nvidia-tesla-p100-minsky,32661.html
)

There is also discussion around using this for device accelerated page
migration. That can help with coherent device memory node work.
(https://lkml.kernel.org/r/1477283517-2504-1-git-send-email-khandual@linux.vnet.ibm.com)

-aneesh

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: "John Hubbard" <jhubbard@nvidia.com>,
	"Jérôme Glisse" <jglisse@redhat.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [HMM v13 00/18] HMM (Heterogeneous Memory Management) v13
Date: Sat, 19 Nov 2016 20:20:35 +0530	[thread overview]
Message-ID: <8760njmslg.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.LNX.2.20.1611181638370.53648@blueforge.nvidia.com>

John Hubbard <jhubbard@nvidia.com> writes:

> On Fri, 18 Nov 2016, Jérôme Glisse wrote:
>
>> Cliff note: HMM offers 2 things (each standing on its own). First
>> it allows to use device memory transparently inside any process
>> without any modifications to process program code. Second it allows
>> to mirror process address space on a device.
>> 
>> Change since v12 is the use of struct page for device memory even if
>> the device memory is not accessible by the CPU (because of limitation
>> impose by the bus between the CPU and the device).
>> 
>> Using struct page means that their are minimal changes to core mm
>> code. HMM build on top of ZONE_DEVICE to provide struct page, it
>> adds new features to ZONE_DEVICE. The first 7 patches implement
>> those changes.
>> 
>> Rest of patchset is divided into 3 features that can each be use
>> independently from one another. First is the process address space
>> mirroring (patch 9 to 13), this allow to snapshot CPU page table
>> and to keep the device page table synchronize with the CPU one.
>> 
>> Second is a new memory migration helper which allow migration of
>> a range of virtual address of a process. This memory migration
>> also allow device to use their own DMA engine to perform the copy
>> between the source memory and destination memory. This can be
>> usefull even outside HMM context in many usecase.
>> 
>> Third part of the patchset (patch 17-18) is a set of helper to
>> register a ZONE_DEVICE node and manage it. It is meant as a
>> convenient helper so that device drivers do not each have to
>> reimplement over and over the same boiler plate code.
>> 
>> 
>> I am hoping that this can now be consider for inclusion upstream.
>> Bottom line is that without HMM we can not support some of the new
>> hardware features on x86 PCIE. I do believe we need some solution
>> to support those features or we won't be able to use such hardware
>> in standard like C++17, OpenCL 3.0 and others.
>> 
>> I have been working with NVidia to bring up this feature on their
>> Pascal GPU. There are real hardware that you can buy today that
>> could benefit from HMM. We also intend to leverage this inside the
>> open source nouveau driver.
>> 
>
> Hi,
>
> We (NVIDIA engineering) have been working closely with Jerome on this for 
> several years now, and I wanted to mention that NVIDIA is committed to 
> using HMM. We've done initial testing of this patchset on Pascal GPUs (a 
> bit more detail below) and it is looking good.
>   

This can also be used on IBM platforms like Minsky (
http://www.tomshardware.com/news/ibm-power8-nvidia-tesla-p100-minsky,32661.html
)

There is also discussion around using this for device accelerated page
migration. That can help with coherent device memory node work.
(https://lkml.kernel.org/r/1477283517-2504-1-git-send-email-khandual@linux.vnet.ibm.com)

-aneesh

  reply	other threads:[~2016-11-19 14:50 UTC|newest]

Thread overview: 146+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-18 18:18 [HMM v13 00/18] HMM (Heterogeneous Memory Management) v13 Jérôme Glisse
2016-11-18 18:18 ` Jérôme Glisse
2016-11-18 18:18 ` [HMM v13 01/18] mm/memory/hotplug: convert device parameter bool to set of flags Jérôme Glisse
2016-11-18 18:18   ` Jérôme Glisse
2016-11-21  0:44   ` Balbir Singh
2016-11-21  0:44     ` Balbir Singh
2016-11-21  4:53     ` Jerome Glisse
2016-11-21  4:53       ` Jerome Glisse
2016-11-21  6:57       ` Anshuman Khandual
2016-11-21  6:57         ` Anshuman Khandual
2016-11-21 12:19         ` Jerome Glisse
2016-11-21 12:19           ` Jerome Glisse
2016-11-21  6:41   ` Anshuman Khandual
2016-11-21  6:41     ` Anshuman Khandual
2016-11-21 12:27     ` Jerome Glisse
2016-11-21 12:27       ` Jerome Glisse
2016-11-22  5:35       ` Anshuman Khandual
2016-11-22  5:35         ` Anshuman Khandual
2016-11-22 14:08         ` Jerome Glisse
2016-11-22 14:08           ` Jerome Glisse
2016-11-18 18:18 ` [HMM v13 02/18] mm/ZONE_DEVICE/unaddressable: add support for un-addressable device memory Jérôme Glisse
2016-11-18 18:18   ` Jérôme Glisse
2016-11-21  8:06   ` Anshuman Khandual
2016-11-21  8:06     ` Anshuman Khandual
2016-11-21 12:33     ` Jerome Glisse
2016-11-21 12:33       ` Jerome Glisse
2016-11-22  5:15       ` Anshuman Khandual
2016-11-22  5:15         ` Anshuman Khandual
2016-11-18 18:18 ` [HMM v13 03/18] mm/ZONE_DEVICE/free_hot_cold_page: catch ZONE_DEVICE pages Jérôme Glisse
2016-11-18 18:18   ` Jérôme Glisse
2016-11-21  8:18   ` Anshuman Khandual
2016-11-21  8:18     ` Anshuman Khandual
2016-11-21 12:50     ` Jerome Glisse
2016-11-21 12:50       ` Jerome Glisse
2016-11-22  4:30       ` Anshuman Khandual
2016-11-22  4:30         ` Anshuman Khandual
2016-11-18 18:18 ` [HMM v13 04/18] mm/ZONE_DEVICE/free-page: callback when page is freed Jérôme Glisse
2016-11-18 18:18   ` Jérôme Glisse
2016-11-21  1:49   ` Balbir Singh
2016-11-21  1:49     ` Balbir Singh
2016-11-21  4:57     ` Jerome Glisse
2016-11-21  4:57       ` Jerome Glisse
2016-11-21  8:26   ` Anshuman Khandual
2016-11-21  8:26     ` Anshuman Khandual
2016-11-21 12:34     ` Jerome Glisse
2016-11-21 12:34       ` Jerome Glisse
2016-11-22  5:02       ` Anshuman Khandual
2016-11-22  5:02         ` Anshuman Khandual
2016-11-18 18:18 ` [HMM v13 05/18] mm/ZONE_DEVICE/devmem_pages_remove: allow early removal of device memory Jérôme Glisse
2016-11-18 18:18   ` Jérôme Glisse
2016-11-21 10:37   ` Anshuman Khandual
2016-11-21 10:37     ` Anshuman Khandual
2016-11-21 12:39     ` Jerome Glisse
2016-11-21 12:39       ` Jerome Glisse
2016-11-22  4:54       ` Anshuman Khandual
2016-11-22  4:54         ` Anshuman Khandual
2016-11-18 18:18 ` [HMM v13 06/18] mm/ZONE_DEVICE/unaddressable: add special swap for unaddressable Jérôme Glisse
2016-11-18 18:18   ` Jérôme Glisse
2016-11-21  2:06   ` Balbir Singh
2016-11-21  2:06     ` Balbir Singh
2016-11-21  5:05     ` Jerome Glisse
2016-11-21  5:05       ` Jerome Glisse
2016-11-22  2:19       ` Balbir Singh
2016-11-22  2:19         ` Balbir Singh
2016-11-22 13:59         ` Jerome Glisse
2016-11-22 13:59           ` Jerome Glisse
2016-11-21 11:10     ` Anshuman Khandual
2016-11-21 11:10       ` Anshuman Khandual
2016-11-21 10:58   ` Anshuman Khandual
2016-11-21 10:58     ` Anshuman Khandual
2016-11-21 12:42     ` Jerome Glisse
2016-11-21 12:42       ` Jerome Glisse
2016-11-22  4:48       ` Anshuman Khandual
2016-11-22  4:48         ` Anshuman Khandual
2016-11-24 13:56         ` Jerome Glisse
2016-11-24 13:56           ` Jerome Glisse
2016-11-18 18:18 ` [HMM v13 07/18] mm/ZONE_DEVICE/x86: add support for un-addressable device memory Jérôme Glisse
2016-11-18 18:18   ` Jérôme Glisse
2016-11-21  2:08   ` Balbir Singh
2016-11-21  2:08     ` Balbir Singh
2016-11-21  5:08     ` Jerome Glisse
2016-11-21  5:08       ` Jerome Glisse
2016-11-18 18:18 ` [HMM v13 08/18] mm/hmm: heterogeneous memory management (HMM for short) Jérôme Glisse
2016-11-18 18:18   ` Jérôme Glisse
2016-11-21  2:29   ` Balbir Singh
2016-11-21  2:29     ` Balbir Singh
2016-11-21  5:14     ` Jerome Glisse
2016-11-21  5:14       ` Jerome Glisse
2016-11-23  4:03   ` Anshuman Khandual
2016-11-23  4:03     ` Anshuman Khandual
2016-11-27 13:10     ` Jerome Glisse
2016-11-27 13:10       ` Jerome Glisse
2016-11-28  2:58       ` Anshuman Khandual
2016-11-28  2:58         ` Anshuman Khandual
2016-11-28  9:41         ` Jerome Glisse
2016-11-28  9:41           ` Jerome Glisse
2016-11-18 18:18 ` [HMM v13 09/18] mm/hmm/mirror: mirror process address space on device with HMM helpers Jérôme Glisse
2016-11-18 18:18   ` Jérôme Glisse
2016-11-21  2:42   ` Balbir Singh
2016-11-21  2:42     ` Balbir Singh
2016-11-21  5:18     ` Jerome Glisse
2016-11-21  5:18       ` Jerome Glisse
2016-11-18 18:18 ` [HMM v13 10/18] mm/hmm/mirror: add range lock helper, prevent CPU page table update for the range Jérôme Glisse
2016-11-18 18:18   ` Jérôme Glisse
2016-11-18 18:18 ` [HMM v13 11/18] mm/hmm/mirror: add range monitor helper, to monitor CPU page table update Jérôme Glisse
2016-11-18 18:18   ` Jérôme Glisse
2016-11-18 18:18 ` [HMM v13 12/18] mm/hmm/mirror: helper to snapshot CPU page table Jérôme Glisse
2016-11-18 18:18   ` Jérôme Glisse
2016-11-18 18:18 ` [HMM v13 13/18] mm/hmm/mirror: device page fault handler Jérôme Glisse
2016-11-18 18:18   ` Jérôme Glisse
2016-11-18 18:18 ` [HMM v13 14/18] mm/hmm/migrate: support un-addressable ZONE_DEVICE page in migration Jérôme Glisse
2016-11-18 18:18   ` Jérôme Glisse
2016-11-18 18:18 ` [HMM v13 15/18] mm/hmm/migrate: add new boolean copy flag to migratepage() callback Jérôme Glisse
2016-11-18 18:18   ` Jérôme Glisse
2016-11-18 18:18 ` [HMM v13 16/18] mm/hmm/migrate: new memory migration helper for use with device memory Jérôme Glisse
2016-11-18 18:18   ` Jérôme Glisse
2016-11-18 19:57   ` Aneesh Kumar K.V
2016-11-18 19:57     ` Aneesh Kumar K.V
2016-11-18 20:15     ` Jerome Glisse
2016-11-18 20:15       ` Jerome Glisse
2016-11-19 14:32   ` Aneesh Kumar K.V
2016-11-19 14:32     ` Aneesh Kumar K.V
2016-11-19 17:17     ` Jerome Glisse
2016-11-19 17:17       ` Jerome Glisse
2016-11-20 18:21       ` Aneesh Kumar K.V
2016-11-20 18:21         ` Aneesh Kumar K.V
2016-11-20 20:06         ` Jerome Glisse
2016-11-20 20:06           ` Jerome Glisse
2016-11-21  3:30   ` Balbir Singh
2016-11-21  3:30     ` Balbir Singh
2016-11-21  5:31     ` Jerome Glisse
2016-11-21  5:31       ` Jerome Glisse
2016-11-18 18:18 ` [HMM v13 17/18] mm/hmm/devmem: device driver helper to hotplug ZONE_DEVICE memory Jérôme Glisse
2016-11-18 18:18   ` Jérôme Glisse
2016-11-18 18:18 ` [HMM v13 18/18] mm/hmm/devmem: dummy HMM device as an helper for " Jérôme Glisse
2016-11-18 18:18   ` Jérôme Glisse
2016-11-19  0:41 ` [HMM v13 00/18] HMM (Heterogeneous Memory Management) v13 John Hubbard
2016-11-19  0:41   ` John Hubbard
2016-11-19 14:50   ` Aneesh Kumar K.V [this message]
2016-11-19 14:50     ` Aneesh Kumar K.V
2016-11-23  9:16 ` Haggai Eran
2016-11-23  9:16   ` Haggai Eran
2016-11-25 16:16   ` Jerome Glisse
2016-11-25 16:16     ` Jerome Glisse
2016-11-27 13:27     ` Haggai Eran
2016-11-27 13:27       ` Haggai Eran

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=8760njmslg.fsf@linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=jglisse@redhat.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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.