From: Andrew Morton <akpm@linux-foundation.org>
To: Balbir Singh <bsingharora@gmail.com>
Cc: "Jérôme Glisse" <jglisse@redhat.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
"John Hubbard" <jhubbard@nvidia.com>,
"Naoya Horiguchi" <n-horiguchi@ah.jp.nec.com>,
"David Nellans" <dnellans@nvidia.com>
Subject: Re: [HMM v17 00/14] HMM (Heterogeneous Memory Management) v17
Date: Wed, 22 Feb 2017 00:16:03 -0800 [thread overview]
Message-ID: <20170222001603.162a1209efc06b6c46556383@linux-foundation.org> (raw)
In-Reply-To: <20170222071915.GE9967@balbir.ozlabs.ibm.com>
On Wed, 22 Feb 2017 18:19:15 +1100 Balbir Singh <bsingharora@gmail.com> wrote:
> On Fri, Jan 27, 2017 at 05:52:07PM -0500, 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 v16:
> > - move HMM unaddressable device memory to its own radix tree and
> > thus find_dev_pagemap() will no longer return HMM dev_pagemap
> > - rename HMM migration helper (drop the prefix) and make them
> > completely independent of HMM
> >
> > Migration can now be use to implement thing like multi-threaded
> > copy or make use of specific memory allocator for destination
> > memory.
> >
> > Work is under way to use this feature inside nouveau (the upstream
> > open source driver for NVidia GPU) either 411 or 4.12 timeframe.
> > But this patchset have been otherwise tested with the close source
> > driver for NVidia GPU and thus we are confident it works and allow
> > to use the hardware for seamless interaction between CPU and GPU
> > in common address space of a process.
> >
> > I also discussed the features with other company and i am confident
> > it can be use on other, yet, unrelease hardware.
> >
> > Please condiser applying for 4.11
> >
>
> Andrew, do we expect to get this in 4.11/4.12? Just curious.
>
I'll be taking a serious look after -rc1.
The lack of reviewed-by, acked-by and tested-by is a concern. It's
rather odd for a patchset in the 17th revision! What's up with that?
Have you reviewed or tested the patches?
next prev parent reply other threads:[~2017-02-22 8:16 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-27 22:52 Jérôme Glisse
2017-01-27 22:52 ` [HMM v17 01/14] mm/memory/hotplug: convert device bool to int to allow for more flags v2 Jérôme Glisse
2017-01-27 22:52 ` [HMM v17 02/14] mm/ZONE_DEVICE/free-page: callback when page is freed v2 Jérôme Glisse
2017-01-27 22:52 ` [HMM v17 03/14] mm/ZONE_DEVICE/unaddressable: add support for un-addressable device memory v3 Jérôme Glisse
2017-01-27 22:52 ` [HMM v17 04/14] mm/ZONE_DEVICE/x86: add support for un-addressable device memory Jérôme Glisse
2017-01-27 22:52 ` [HMM v17 05/14] mm/migrate: add new boolean copy flag to migratepage() callback Jérôme Glisse
2017-01-27 22:52 ` [HMM v17 06/14] mm/migrate: new memory migration helper for use with device memory v3 Jérôme Glisse
2017-02-22 15:31 ` Reza Arbab
2017-01-27 22:52 ` [HMM v17 07/14] mm/migrate: migrate_vma() unmap page from vma while collecting pages Jérôme Glisse
2017-01-27 22:52 ` [HMM v17 08/14] mm/hmm: heterogeneous memory management (HMM for short) Jérôme Glisse
2017-01-27 22:52 ` [HMM v17 09/14] mm/hmm/mirror: mirror process address space on device with HMM helpers Jérôme Glisse
2017-03-13 22:10 ` Krishna Reddy
2017-01-27 22:52 ` [HMM v17 10/14] mm/hmm/mirror: helper to snapshot CPU page table Jérôme Glisse
2017-01-27 22:52 ` [HMM v17 11/14] mm/hmm/mirror: device page fault handler Jérôme Glisse
2017-01-27 22:52 ` [HMM v17 12/14] mm/hmm/migrate: support un-addressable ZONE_DEVICE page in migration Jérôme Glisse
2017-01-27 22:52 ` [HMM v17 13/14] mm/hmm/devmem: device memory hotplug using ZONE_DEVICE Jérôme Glisse
2017-01-27 22:52 ` [HMM v17 14/14] mm/hmm/devmem: dummy HMM device for ZONE_DEVICE memory v2 Jérôme Glisse
2017-01-28 5:39 ` [HMM v17 00/14] HMM (Heterogeneous Memory Management) v17 John Hubbard
2017-02-22 7:19 ` Balbir Singh
2017-02-22 8:16 ` Andrew Morton [this message]
2017-02-22 8:27 ` Balbir Singh
2017-02-22 15:49 ` Reza Arbab
2017-02-22 23:58 ` John Hubbard
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=20170222001603.162a1209efc06b6c46556383@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=bsingharora@gmail.com \
--cc=dnellans@nvidia.com \
--cc=jglisse@redhat.com \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=n-horiguchi@ah.jp.nec.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
all inboxes | Powered by JetHome®