linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* Heterogeneous memory management v2
@ 2014-06-12 18:33 j.glisse
  2014-06-12 18:57 ` [PATCH 1/5] mm: differentiate unmap for vmscan from other unmap j.glisse
  0 siblings, 1 reply; 7+ messages in thread
From: j.glisse @ 2014-06-12 18:33 UTC (permalink / raw)
  To: akpm
  Cc: linux-kernel, linux-mm, linux-fsdevel, Linus Torvalds,
	Mel Gorman, H. Peter Anvin, Peter Zijlstra, Linda Wang,
	Kevin E Martin, Jerome Glisse, Andrea Arcangeli, Johannes Weiner,
	Larry Woodman, Rik van Riel, Dave Airlie, Jeff Law,
	Brendan Conoboy, Joe Donohue, Duncan Poole, Sherry Cheung,
	Subhash Gutti, John Hubbard, Mark Hairgrove, Lucien Dunning,
	Cameron Buschardt, Arvind Gopalakrishnan, Haggai Eran,
	Or Gerlitz, Sagi Grimberg, Shachar Raindel, Liran Liss,
	Roland Dreier, Sander, Ben, Stoner, Greg, Bridgman, John, Mantor,
	Michael, Blinzer, Paul, Morichetti, Laurent, Deucher, Alexander,
	Gabbay, Oded

This is a v2 of the hmm patchset. I intentionaly removed the remote memory
support from this version as i would like to see the basic hmm foundation
merge for next kernel (3.17). It apply on top of linux-next.

Below is the nutshell and motivation for hmm. Anyone more curious should
refer to my previous email as it contains a deeper analysis. I should stress
again that dedicated video memory is not vanishing on the contrary the
bandwidth and latency gap between system memory and dedicated video memory
is growing.

Also as stated in previous discusion, hmm can only be implemented using the
mmu_notifier api (or it would need to insert callback in all same spot as
the mmu_notifier). What hmm needs can not be achieve during tlb flush.


In a nutshell:

The heterogeneous memory management (hmm) patchset implement a new api that
sit on top of the mmu notifier api. It provides a simple api to device driver
to mirror a process address space without having to lock or take reference on
page and block them from being reclam or migrated. Any changes on a process
address space is mirrored to the device page table by the hmm code. To achieve
this not only we need each driver to implement a set of callback functions but
hmm also interface itself in many key location of the mm code and fs code.
Moreover hmm allow to migrate range of memory to the device remote memory to
take advantages of its lower latency and higher bandwidth.

The why:

We want to be able to mirror a process address space so that compute api such
as OpenCL or other similar api can start using the exact same address space on
the GPU as on the CPU. This will greatly simplify usages of those api. Moreover
we believe that we will see more and more specialize unit functions that will
want to mirror process address using their own mmu.


Cheers,
JA(C)rA'me Glisse


To: "Andrew Morton" <akpm@linux-foundation.org>,
Cc: <linux-kernel@vger.kernel.org>,
Cc: linux-mm <linux-mm@kvack.org>,
Cc: <linux-fsdevel@vger.kernel.org>,
Cc: "Linus Torvalds" <torvalds@linux-foundation.org>,
Cc: "Mel Gorman" <mgorman@suse.de>,
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Cc: "Peter Zijlstra" <peterz@infradead.org>,
Cc: "Linda Wang" <lwang@redhat.com>,
Cc: "Kevin E Martin" <kem@redhat.com>,
Cc: "Jerome Glisse" <jglisse@redhat.com>,
Cc: "Andrea Arcangeli" <aarcange@redhat.com>,
Cc: "Johannes Weiner" <jweiner@redhat.com>,
Cc: "Larry Woodman" <lwoodman@redhat.com>,
Cc: "Rik van Riel" <riel@redhat.com>,
Cc: "Dave Airlie" <airlied@redhat.com>,
Cc: "Jeff Law" <law@redhat.com>,
Cc: "Brendan Conoboy" <blc@redhat.com>,
Cc: "Joe Donohue" <jdonohue@redhat.com>,
Cc: "Duncan Poole" <dpoole@nvidia.com>,
Cc: "Sherry Cheung" <SCheung@nvidia.com>,
Cc: "Subhash Gutti" <sgutti@nvidia.com>,
Cc: "John Hubbard" <jhubbard@nvidia.com>,
Cc: "Mark Hairgrove" <mhairgrove@nvidia.com>,
Cc: "Lucien Dunning" <ldunning@nvidia.com>,
Cc: "Cameron Buschardt" <cabuschardt@nvidia.com>,
Cc: "Arvind Gopalakrishnan" <arvindg@nvidia.com>,
Cc: "Haggai Eran" <haggaie@mellanox.com>,
Cc: "Or Gerlitz" <ogerlitz@mellanox.com>,
Cc: "Sagi Grimberg" <sagig@mellanox.com>
Cc: "Shachar Raindel" <raindel@mellanox.com>,
Cc: "Liran Liss" <liranl@mellanox.com>,
Cc: "Roland Dreier" <roland@purestorage.com>,
Cc: "Sander, Ben" <ben.sander@amd.com>,
Cc: "Stoner, Greg" <Greg.Stoner@amd.com>,
Cc: "Bridgman, John" <John.Bridgman@amd.com>,
Cc: "Mantor, Michael" <Michael.Mantor@amd.com>,
Cc: "Blinzer, Paul" <Paul.Blinzer@amd.com>,
Cc: "Morichetti, Laurent" <Laurent.Morichetti@amd.com>,
Cc: "Deucher, Alexander" <Alexander.Deucher@amd.com>,
Cc: "Gabbay, Oded" <Oded.Gabbay@amd.com>,


--
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>

^ permalink raw reply	[flat|nested] 7+ messages in thread
* HMM (Heterogeneous Memory Management) v3
@ 2014-06-14  0:48 Jérôme Glisse
  2014-06-14  0:48 ` [PATCH 1/5] mm: differentiate unmap for vmscan from other unmap Jérôme Glisse
  0 siblings, 1 reply; 7+ messages in thread
From: Jérôme Glisse @ 2014-06-14  0:48 UTC (permalink / raw)
  To: akpm, linux-mm, linux-kernel
  Cc: mgorman, hpa, peterz, torvalds, aarcange, riel, jweiner

This v3 of HMM patchset previous discussion can be found at :
http://comments.gmane.org/gmane.linux.kernel.mm/116584

We would like to see this included especialy all preparatory patches are
they are cumberstone to rebase. They do not change any behavior except a
slightly increased stack consumption by adding new argument to mmu notifier
callback. I believe that those added argument might be of value not only
to HMM but also to other user of the mmu_notifier API.

I hide the HMM core function behind staging so people understand this is
not production ready but a base onto which we want to build support for all
HMM features.

In nutshell HMM is an API to simplify mirroring a process address space on
a secondary MMU that has its own page table (and most likely a different
page table format incompatible with the architecture page table). To ensure
that at all time CPU and mirroring device use the same page for the same
address for a process the use of the mmu notifier API is the only sane way.
This is because each CPU page table update is preceded or followed by a call
to the mmu notifier.

Andrew if you fear this feature will not be use by anyone i can ask NVidia
and/or AMD to public state their interest in it. So far HMM have been
developed in a close collaboration with NVidia but at Red Hat (and NVidia
is on board here) we want to make this as usefull as possible to other
consumer too and not only for GPU. So any one who has hardware with its
own MMU and its own page table and who wish to mirror a process address
space is welcome to join the discussion and to ask for features or to
discuss the API we expose to the device driver.

Like i said in v2, i stripped the remote memory support from this patchset
in order to make it easier to get the foundation in so that the remote
memory support is easier and less painfull to work on.

Changed since v2:
  - Hide core hmm behind staging
  - Fixed up all checkpatch.pl issues
  - Rebase on top of lastest linux-next

Note that the dummy driver is not necesarily to be included i added it
here so people can see an example driver. I however intend to grow the
functionalities of the hmm dummy driver in order to make a test and
regression suite for the core hmm.

Cheers,
JA(C)rA'me Glisse

--
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>

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2014-06-14  0:49 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-12 18:33 Heterogeneous memory management v2 j.glisse
2014-06-12 18:57 ` [PATCH 1/5] mm: differentiate unmap for vmscan from other unmap j.glisse
2014-06-12 18:57   ` [PATCH 2/5] mmu_notifier: add action information to address invalidation j.glisse
2014-06-12 18:57   ` [PATCH 3/5] mmu_notifier: pass through vma to invalidate_range and invalidate_page j.glisse
2014-06-12 18:57   ` [PATCH 4/5] hmm: heterogeneous memory management v2 j.glisse
2014-06-12 18:57   ` [PATCH 5/5] hmm/dummy: dummy driver to showcase the hmm api j.glisse
2014-06-14  0:48 HMM (Heterogeneous Memory Management) v3 Jérôme Glisse
2014-06-14  0:48 ` [PATCH 1/5] mm: differentiate unmap for vmscan from other unmap Jérôme Glisse
2014-06-14  0:48   ` [PATCH 2/5] mmu_notifier: add action information to address invalidation Jérôme Glisse

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox