From: Rik van Riel <riel@redhat.com>
To: j.glisse@gmail.com, akpm@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
"Linus Torvalds" <torvalds@linux-foundation.org>,
joro@8bytes.org, "Mel Gorman" <mgorman@suse.de>,
"H. Peter Anvin" <hpa@zytor.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Andrea Arcangeli" <aarcange@redhat.com>,
"Johannes Weiner" <jweiner@redhat.com>,
"Larry Woodman" <lwoodman@redhat.com>,
"Dave Airlie" <airlied@redhat.com>,
"Brendan Conoboy" <blc@redhat.com>,
"Joe Donohue" <jdonohue@redhat.com>,
"Duncan Poole" <dpoole@nvidia.com>,
"Sherry Cheung" <SCheung@nvidia.com>,
"Subhash Gutti" <sgutti@nvidia.com>,
"John Hubbard" <jhubbard@nvidia.com>,
"Mark Hairgrove" <mhairgrove@nvidia.com>,
"Lucien Dunning" <ldunning@nvidia.com>,
"Cameron Buschardt" <cabuschardt@nvidia.com>,
"Arvind Gopalakrishnan" <arvindg@nvidia.com>,
"Shachar Raindel" <raindel@mellanox.com>,
"Liran Liss" <liranl@mellanox.com>,
"Roland Dreier" <roland@purestorage.com>,
"Ben Sander" <ben.sander@amd.com>,
"Greg Stoner" <Greg.Stoner@amd.com>,
"John Bridgman" <John.Bridgman@amd.com>,
"Michael Mantor" <Michael.Mantor@amd.com>,
"Paul Blinzer" <Paul.Blinzer@amd.com>,
"Laurent Morichetti" <Laurent.Morichetti@amd.com>,
"Alexander Deucher" <Alexander.Deucher@amd.com>,
"Oded Gabbay" <Oded.Gabbay@amd.com>,
"Jérôme Glisse" <jglisse@redhat.com>,
"Jatin Kumar" <jakumar@nvidia.com>
Subject: Re: [PATCH 4/5] hmm: heterogeneous memory management v6
Date: Fri, 07 Nov 2014 16:35:57 -0500 [thread overview]
Message-ID: <545D3B3D.50907@redhat.com> (raw)
In-Reply-To: <1415047353-29160-5-git-send-email-j.glisse@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/03/2014 03:42 PM, j.glisse@gmail.com wrote:
> From: JA(C)rA'me Glisse <jglisse@redhat.com>
>
> Motivation:
>
> Heterogeneous memory management is intended to allow a device to
> transparently access a process address space without having to lock
> pages of the process or take references on them. In other word
> mirroring a process address space while allowing the regular memory
> management event such as page reclamation or page migration, to
> happen seamlessly.
>
> Recent years have seen a surge into the number of specialized
> devices that are part of a computer platform (from desktop to
> phone). So far each of those devices have operated on there own
> private address space that is not link or expose to the process
> address space that is using them. This separation often leads to
> multiple memory copy happening between the device owned memory and
> the process memory. This of course is both a waste of cpu cycle and
> memory.
>
> Over the last few years most of those devices have gained a full
> mmu allowing them to support multiple page table, page fault and
> other features that are found inside cpu mmu. There is now a strong
> incentive to start leveraging capabilities of such devices and to
> start sharing process address to avoid any unnecessary memory copy
> as well as simplifying the programming model of those devices by
> sharing an unique and common address space with the process that
> use them.
>
> The aim of the heterogeneous memory management is to provide a
> common API that can be use by any such devices in order to mirror
> process address. The hmm code provide an unique entry point and
> interface itself with the core mm code of the linux kernel avoiding
> duplicate implementation and shielding device driver code from core
> mm code.
Acked-by: Rik van Riel <riel@redhat.com>
- --
All rights reversed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJUXTs9AAoJEM553pKExN6DhSYIAI41vr6c/vVdIg2m6Wq3DiSS
KtBTUX5/cFmvh9Zd3S422ZwzJQ6ZZLGsNuh2LajLqR0dhDKkwxS7FWFSdifcAfq2
B/Xq8JyeW98Fa0OP0V4uqMuo1FMvlXFZsDijFefxo5F2T/H6XyRI2M+f4w5w9iZa
3EvUaFHoG+mCjoR+ANuxwR9J048wWF626R6CHPOvvIKDNRVr+LADvLMBXmbnrYJs
643mmjhNT+EdPQbxBVszsUbBo/mGicRBuW+t3XkWy1g+hsa4AewhHnOuSHDr13zM
YBFjeGP1TbOQxtkiJetsAE4pKxSlJDoscp7vbJjYzLz3Kk2Fag3r1kpSU8S8stI=
=ucI+
-----END PGP SIGNATURE-----
--
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: Rik van Riel <riel@redhat.com>
To: j.glisse@gmail.com, akpm@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
"Linus Torvalds" <torvalds@linux-foundation.org>,
joro@8bytes.org, "Mel Gorman" <mgorman@suse.de>,
"H. Peter Anvin" <hpa@zytor.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Andrea Arcangeli" <aarcange@redhat.com>,
"Johannes Weiner" <jweiner@redhat.com>,
"Larry Woodman" <lwoodman@redhat.com>,
"Dave Airlie" <airlied@redhat.com>,
"Brendan Conoboy" <blc@redhat.com>,
"Joe Donohue" <jdonohue@redhat.com>,
"Duncan Poole" <dpoole@nvidia.com>,
"Sherry Cheung" <SCheung@nvidia.com>,
"Subhash Gutti" <sgutti@nvidia.com>,
"John Hubbard" <jhubbard@nvidia.com>,
"Mark Hairgrove" <mhairgrove@nvidia.com>,
"Lucien Dunning" <ldunning@nvidia.com>,
"Cameron Buschardt" <cabuschardt@nvidia.com>,
"Arvind Gopalakrishnan" <arvindg@nvidia.com>,
"Shachar Raindel" <raindel@mellanox.com>,
"Liran Liss" <liranl@mellanox.com>,
"Roland Dreier" <roland@purestorage.com>,
"Ben Sander" <ben.sander@amd.com>,
"Greg Stoner" <Greg.Stoner@amd.com>,
"John Bridgman" <John.Bridgman@amd.com>,
"Michael Mantor" <Michael.Mantor@amd.com>,
"Paul Blinzer" <Paul.Blinzer@amd.com>,
"Laurent Morichetti" <Laurent.Morichetti@amd.com>,
"Alexander Deucher" <Alexander.Deucher@amd.com>,
"Oded Gabbay" <Oded.Gabbay@amd.com>,
"Jérôme Glisse" <jglisse@redhat.com>,
"Jatin Kumar" <jakumar@nvidia.com>
Subject: Re: [PATCH 4/5] hmm: heterogeneous memory management v6
Date: Fri, 07 Nov 2014 16:35:57 -0500 [thread overview]
Message-ID: <545D3B3D.50907@redhat.com> (raw)
In-Reply-To: <1415047353-29160-5-git-send-email-j.glisse@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/03/2014 03:42 PM, j.glisse@gmail.com wrote:
> From: Jérôme Glisse <jglisse@redhat.com>
>
> Motivation:
>
> Heterogeneous memory management is intended to allow a device to
> transparently access a process address space without having to lock
> pages of the process or take references on them. In other word
> mirroring a process address space while allowing the regular memory
> management event such as page reclamation or page migration, to
> happen seamlessly.
>
> Recent years have seen a surge into the number of specialized
> devices that are part of a computer platform (from desktop to
> phone). So far each of those devices have operated on there own
> private address space that is not link or expose to the process
> address space that is using them. This separation often leads to
> multiple memory copy happening between the device owned memory and
> the process memory. This of course is both a waste of cpu cycle and
> memory.
>
> Over the last few years most of those devices have gained a full
> mmu allowing them to support multiple page table, page fault and
> other features that are found inside cpu mmu. There is now a strong
> incentive to start leveraging capabilities of such devices and to
> start sharing process address to avoid any unnecessary memory copy
> as well as simplifying the programming model of those devices by
> sharing an unique and common address space with the process that
> use them.
>
> The aim of the heterogeneous memory management is to provide a
> common API that can be use by any such devices in order to mirror
> process address. The hmm code provide an unique entry point and
> interface itself with the core mm code of the linux kernel avoiding
> duplicate implementation and shielding device driver code from core
> mm code.
Acked-by: Rik van Riel <riel@redhat.com>
- --
All rights reversed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJUXTs9AAoJEM553pKExN6DhSYIAI41vr6c/vVdIg2m6Wq3DiSS
KtBTUX5/cFmvh9Zd3S422ZwzJQ6ZZLGsNuh2LajLqR0dhDKkwxS7FWFSdifcAfq2
B/Xq8JyeW98Fa0OP0V4uqMuo1FMvlXFZsDijFefxo5F2T/H6XyRI2M+f4w5w9iZa
3EvUaFHoG+mCjoR+ANuxwR9J048wWF626R6CHPOvvIKDNRVr+LADvLMBXmbnrYJs
643mmjhNT+EdPQbxBVszsUbBo/mGicRBuW+t3XkWy1g+hsa4AewhHnOuSHDr13zM
YBFjeGP1TbOQxtkiJetsAE4pKxSlJDoscp7vbJjYzLz3Kk2Fag3r1kpSU8S8stI=
=ucI+
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2014-11-07 21:36 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-03 20:42 HMM (heterogeneous memory management) v5 j.glisse
2014-11-03 20:42 ` j.glisse
2014-11-03 20:42 ` j.glisse
2014-11-03 20:42 ` [PATCH 1/5] mmu_notifier: add event information to address invalidation v5 j.glisse
2014-11-03 20:42 ` j.glisse
2014-11-06 17:16 ` Rik van Riel
2014-11-06 17:16 ` Rik van Riel
2014-11-03 20:42 ` [PATCH 2/5] mmu_notifier: keep track of active invalidation ranges j.glisse
2014-11-03 20:42 ` j.glisse
2014-11-06 21:03 ` Rik van Riel
2014-11-06 21:03 ` Rik van Riel
2014-11-03 20:42 ` [PATCH 3/5] lib: lockless generic and arch independent page table (gpt) v2 j.glisse
2014-11-03 20:42 ` j.glisse
2014-11-06 22:32 ` Rik van Riel
2014-11-06 22:32 ` Rik van Riel
2014-11-06 22:40 ` Jerome Glisse
2014-11-06 22:40 ` Jerome Glisse
2014-11-06 22:56 ` Rik van Riel
2014-11-06 22:56 ` Rik van Riel
2014-11-03 20:42 ` [PATCH 4/5] hmm: heterogeneous memory management v6 j.glisse
2014-11-03 20:42 ` j.glisse
2014-11-07 21:35 ` Rik van Riel [this message]
2014-11-07 21:35 ` Rik van Riel
2014-11-03 20:42 ` [PATCH 5/5] hmm/dummy: dummy driver to showcase the hmm api v3 j.glisse
2014-11-03 20:42 ` j.glisse
2014-11-07 21:37 ` Rik van Riel
2014-11-07 21:37 ` Rik van Riel
-- strict thread matches above, loose matches on Subject: below --
2014-11-10 18:28 HMM (heterogeneous memory management) v6 j.glisse
2014-11-10 18:28 ` [PATCH 4/5] hmm: heterogeneous memory management v6 j.glisse
2014-11-10 18:28 ` j.glisse
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=545D3B3D.50907@redhat.com \
--to=riel@redhat.com \
--cc=Alexander.Deucher@amd.com \
--cc=Greg.Stoner@amd.com \
--cc=John.Bridgman@amd.com \
--cc=Laurent.Morichetti@amd.com \
--cc=Michael.Mantor@amd.com \
--cc=Oded.Gabbay@amd.com \
--cc=Paul.Blinzer@amd.com \
--cc=SCheung@nvidia.com \
--cc=aarcange@redhat.com \
--cc=airlied@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=arvindg@nvidia.com \
--cc=ben.sander@amd.com \
--cc=blc@redhat.com \
--cc=cabuschardt@nvidia.com \
--cc=dpoole@nvidia.com \
--cc=hpa@zytor.com \
--cc=j.glisse@gmail.com \
--cc=jakumar@nvidia.com \
--cc=jdonohue@redhat.com \
--cc=jglisse@redhat.com \
--cc=jhubbard@nvidia.com \
--cc=joro@8bytes.org \
--cc=jweiner@redhat.com \
--cc=ldunning@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liranl@mellanox.com \
--cc=lwoodman@redhat.com \
--cc=mgorman@suse.de \
--cc=mhairgrove@nvidia.com \
--cc=peterz@infradead.org \
--cc=raindel@mellanox.com \
--cc=roland@purestorage.com \
--cc=sgutti@nvidia.com \
--cc=torvalds@linux-foundation.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.