So sorry had to resend because i stupidly forgot to cc mailing list.
Ignore private send done before.
HMM (Heterogeneous Memory Management) is an helper layer for device
that want to mirror a process address space into their own mmu. Main
target is GPU but other hardware, like network device can take also
use HMM.
There is two side to HMM, first one is mirroring of process address
space on behalf of a device. HMM will manage a secondary page table
for the device and keep it synchronize with the CPU page table. HMM
also do DMA mapping on behalf of the device (which would allow new
kind of optimization further down the road (1)).
Second side is allowing to migrate process memory to device memory
where device memory is unmappable by the CPU. Any CPU access will
trigger special fault that will migrate memory back.
>From design point of view not much changed since last patchset (2).
Most of the change are in small details of the API expose to device
driver. This version also include device driver change for Mellanox
hardware to use HMM as an alternative to ODP (which provide a subset
of HMM functionality specificaly for RDMA devices). Long term plan
is to have HMM completely replace ODP.
Why doing this ?
Mirroring a process address space is mandatory with OpenCL 2.0 and
with other GPU compute API. OpenCL 2.0 allow different level of
implementation and currently only the lowest 2 are supported on
Linux. To implement the highest level, where CPU and GPU access
can happen concurently and are cache coherent, HMM is needed, or
something providing same functionality, for instance through
platform hardware.
Hardware solution such as PCIE ATS/PASID is limited to mirroring
system memory and does not provide way to migrate memory to device
memory (which offer significantly more bandwidth up to 10 times
faster than regular system memory with discret GPU, also have
lower latency than PCIE transaction).
Current CPU with GPU on same die (AMD or Intel) use the ATS/PASID
and for Intel a special level of cache (backed by a large pool of
fast memory).
For foreseeable futur, discrete GPU will remain releveant as they
can have a large quantity of faster memory than integrated GPU.
Thus we believe HMM will allow to leverage discret GPU memory in
a transparent fashion to the application, with minimum disruption
to the linux kernel mm code. Also HMM can work along hardware
solution such as PCIE ATS/PASID (leaving regular case to ATS/PASID
while HMM handles the migrated memory case).
Design :
The patch 1, 2, 3 and 4 augment the mmu notifier API with new
informations to more efficiently mirror CPU page table updates.
The first side of HMM, process address space mirroring, is
implemented in patch 5 through 12. This use a secondary page
table, in which HMM mirror memory actively use by the device.
HMM does not take a reference on any of the page, it use the
mmu notifier API to track changes to the CPU page table and to
update the mirror page table. All this while providing a simple
API to device driver.
To implement this we use a "generic" page table and not a radix
tree because we need to store more flags than radix allows and
we need to store dma address (sizeof(dma_addr_t) > sizeof(long)
on some platform). All this is
Patch 14 pass down the lane the new child mm struct of a parent
process being forked. This is necessary to properly handle fork
when parent process have migrated memory (more on that below).
Patch 15 allow to get the current memcg against which anonymous
memory of a process should be accounted. It usefull because in
HMM we do bulk transaction on address space and we wish to avoid
storing a pointer to memcg for each single page. All operation
dealing with memcg happens under the protection of the mmap
semaphore.
Second side of HMM, migration to device memory, is implemented
in patch 16 to 28. This only deal with anonymous memory. A new
special swap type is introduced. Migrated memory will have there
CPU page table entry set to this special swap entry (like the
migration entry but unlike migration this is not a short lived
state).
All the patches are then set of functions that deals with those
special entry in the various code path that might face them.
Memory migration require several steps, first the memory is un-
mapped from CPU and replace with special "locked" entry, HMM
locked entry is a short lived transitional state, this is to
avoid two threads to fight over migration entry.
Once unmapped HMM can determine what can be migrated or not by
comparing mapcount and page count. If something holds a reference
then the page is not migrated and CPU page table is restored.
Next step is to schedule the copy to device memory and update
the CPU page table to regular HMM entry.
Migration back follow the same pattern, replace with special
lock entry, then copy back, then update CPU page table.
(1) Because HMM keeps a secondary page table which keeps track of
DMA mapping, there is room for new optimization. We want to
add a new DMA API to allow to manage DMA page table mapping
at directory level. This would allow to minimize memory
consumption of mirror page table and also over head of doing
DMA mapping page per page. This is a future feature we want
to work on and hope the idea will proove usefull not only to
HMM users.
(2) Previous patchset posting :
v1 http://lwn.net/Articles/597289/
v2 https://lkml.org/lkml/2014/6/12/559
v3 https://lkml.org/lkml/2014/6/13/633
v4 https://lkml.org/lkml/2014/8/29/423
v5 https://lkml.org/lkml/2014/11/3/759
v6 http://lwn.net/Articles/619737/
v7 http://lwn.net/Articles/627316/
Cheers,
Jérôme
To: "Andrew Morton" <akpm@xxxxxxxxxxxxxxxxxxxx>,
Cc: <linux-kernel@xxxxxxxxxxxxxxx>,
Cc: linux-mm <linux-mm@xxxxxxxxx>,
Cc: <linux-fsdevel@xxxxxxxxxxxxxxx>,
Cc: "Linus Torvalds" <torvalds@xxxxxxxxxxxxxxxxxxxx>,
Cc: "Mel Gorman" <mgorman@xxxxxxx>,
Cc: "H. Peter Anvin" <hpa@xxxxxxxxx>,
Cc: "Peter Zijlstra" <peterz@xxxxxxxxxxxxx>,
Cc: "Linda Wang" <lwang@xxxxxxxxxx>,
Cc: "Kevin E Martin" <kem@xxxxxxxxxx>,
Cc: "Andrea Arcangeli" <aarcange@xxxxxxxxxx>,
Cc: "Johannes Weiner" <jweiner@xxxxxxxxxx>,
Cc: "Larry Woodman" <lwoodman@xxxxxxxxxx>,
Cc: "Rik van Riel" <riel@xxxxxxxxxx>,
Cc: "Dave Airlie" <airlied@xxxxxxxxxx>,
Cc: "Jeff Law" <law@xxxxxxxxxx>,
Cc: "Brendan Conoboy" <blc@xxxxxxxxxx>,
Cc: "Joe Donohue" <jdonohue@xxxxxxxxxx>,
Cc: "Duncan Poole" <dpoole@xxxxxxxxxx>,
Cc: "Sherry Cheung" <SCheung@xxxxxxxxxx>,
Cc: "Subhash Gutti" <sgutti@xxxxxxxxxx>,
Cc: "John Hubbard" <jhubbard@xxxxxxxxxx>,
Cc: "Mark Hairgrove" <mhairgrove@xxxxxxxxxx>,
Cc: "Lucien Dunning" <ldunning@xxxxxxxxxx>,
Cc: "Cameron Buschardt" <cabuschardt@xxxxxxxxxx>,
Cc: "Arvind Gopalakrishnan" <arvindg@xxxxxxxxxx>,
Cc: "Haggai Eran" <haggaie@xxxxxxxxxxxx>,
Cc: "Or Gerlitz" <ogerlitz@xxxxxxxxxxxx>,
Cc: "Sagi Grimberg" <sagig@xxxxxxxxxxxx>
Cc: "Shachar Raindel" <raindel@xxxxxxxxxxxx>,
Cc: "Liran Liss" <liranl@xxxxxxxxxxxx>,
Cc: "Roland Dreier" <roland@xxxxxxxxxxxxxxx>,
Cc: "Sander, Ben" <ben.sander@xxxxxxx>,
Cc: "Stoner, Greg" <Greg.Stoner@xxxxxxx>,
Cc: "Bridgman, John" <John.Bridgman@xxxxxxx>,
Cc: "Mantor, Michael" <Michael.Mantor@xxxxxxx>,
Cc: "Blinzer, Paul" <Paul.Blinzer@xxxxxxx>,
Cc: "Morichetti, Laurent" <Laurent.Morichetti@xxxxxxx>,
Cc: "Deucher, Alexander" <Alexander.Deucher@xxxxxxx>,
Cc: "Gabbay, Oded" <Oded.Gabbay@xxxxxxx>,
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
