From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751103AbcCHTqh (ORCPT ); Tue, 8 Mar 2016 14:46:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56002 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750852AbcCHTq1 (ORCPT ); Tue, 8 Mar 2016 14:46:27 -0500 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= To: akpm@linux-foundation.org, , linux-mm@kvack.org Cc: Linus Torvalds , , Mel Gorman , "H. Peter Anvin" , Peter Zijlstra , Andrea Arcangeli , Johannes Weiner , Larry Woodman , Rik van Riel , Dave Airlie , Brendan Conoboy , Joe Donohue , Christophe Harle , Duncan Poole , Sherry Cheung , Subhash Gutti , John Hubbard , Mark Hairgrove , Lucien Dunning , Cameron Buschardt , Arvind Gopalakrishnan , Haggai Eran , Shachar Raindel , Liran Liss , Roland Dreier , Ben Sander , Greg Stoner , John Bridgman , Michael Mantor , Paul Blinzer , Leonid Shamis , Laurent Morichetti , Alexander Deucher , "Linda Wang" , "Kevin E Martin" , "Jeff Law" , "Or Gerlitz" , "Sagi Grimberg" , "Aneesh Kumar K.V" Subject: HMM (Heterogeneous Memory Management) Date: Tue, 8 Mar 2016 15:42:53 -0500 Message-Id: <1457469802-11850-1-git-send-email-jglisse@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Last time I spoke with Linus and Andrew, the requirement for getting HMM upstream was having real hardware working with it beside Mellanox (as Mellanox does not use all HMM features), both with closed source driver and open source driver. Work on open source driver is underway, and I anticipate we will get update from NVIDIA and other parties on their efforts and plans shortly. I am re-posting now because I want people to have time to look at HMM again. The open source driver will stay behind close doors until hardware is released. I can however have the upstream maintainer share his progress here if anyone feels the need for that. Other parties such as IBM and Mediatek are also interested in HMM. I expect they will comment on their respective hardware when they can. I hope that HMM can be considered for inclusion upstream soon. This version is virtualy the same as the one since last post (modulo rebase differences). Tree with the patchset: git://people.freedesktop.org/~glisse/linux hmm-v12 branch HMM (HMM (Heterogeneous Memory Management) is an helper layer for device driver, its main features are : - Shadow CPU page table of a process into a device specific format page table and keep both page table synchronize. - Handle DMA mapping of system ram page on behalf of device (for shadowed page table entry). - Migrate private anonymous memory to private device memory and handle CPU page fault (which triggers a migration back to system memory so CPU can access it). Benefits of HMM : - Avoid current model where device driver have to pin page which blocks several kernel features (KSM, migration, ...). - No impact on existing workload that do not use HMM (it only adds couple more if() to common code path). - Intended as common infrastructure for various hardware. - Allow userspace API to move away from explicit copy code path where application programmer has to manage manually memcpy to and from device memory. - Transparent to userspace, for instance allowing library to use GPU without involving application linked against it. Change log : v12: - Rebase v11: - Fix PROT_NONE case - Fix missing page table walk callback - Add support for hugetlbfs v10: - Minor fixes here and there. v9: - Added new device driver helpers. - Added documentions. - Improved page table code claritity (minor architectural changes and better names). v8: - Removed currently unuse fence code. - Added DMA mapping on behalf of device. v7: - Redone and simplified page table code to match Linus suggestion http://article.gmane.org/gmane.linux.kernel.mm/125257 ... Lost in translation ... Why doing this ? Mirroring a process address space is mandatory with OpenCL 2.0 and with other GPU compute APIs. OpenCL 2.0 allows 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 discrete 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 future, discrete GPUs will remain releveant as they can have a large quantity of faster memory than integrated GPU. Thus we believe HMM will allow us to leverage discrete GPUs 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 14. 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 tree allows and we need to store dma address (sizeof(dma_addr_t) > sizeof(long) on some platform). (1) 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/ v8 https://lwn.net/Articles/645515/ v9 https://lwn.net/Articles/651553/ v10 https://lwn.net/Articles/654430/ v11 https://lkml.org/lkml/2015/10/21/739 Cheers, Jérôme To: "Andrew Morton" , To: , To: linux-mm , Cc: "Linus Torvalds" , Cc: "Mel Gorman" , Cc: "H. Peter Anvin" , Cc: "Peter Zijlstra" , Cc: "Linda Wang" , Cc: "Kevin E Martin" , Cc: "Andrea Arcangeli" , Cc: "Johannes Weiner" , Cc: "Larry Woodman" , Cc: "Rik van Riel" , Cc: "Dave Airlie" , Cc: "Jeff Law" , Cc: "Brendan Conoboy" , Cc: "Joe Donohue" , Cc: "Christophe Harle" , Cc: "Duncan Poole" , Cc: "Sherry Cheung" , Cc: "Subhash Gutti" , Cc: "John Hubbard" , Cc: "Mark Hairgrove" , Cc: "Lucien Dunning" , Cc: "Cameron Buschardt" , Cc: "Arvind Gopalakrishnan" , Cc: "Haggai Eran" , Cc: "Or Gerlitz" , Cc: "Sagi Grimberg" Cc: "Shachar Raindel" , Cc: "Liran Liss" , Cc: "Roland Dreier" , Cc: "Sander, Ben" , Cc: "Stoner, Greg" , Cc: "Bridgman, John" , Cc: "Mantor, Michael" , Cc: "Blinzer, Paul" , Cc: "Morichetti, Laurent" , Cc: "Deucher, Alexander" , Cc: "Leonid Shamis" Cc: "Aneesh Kumar K.V" From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) by kanga.kvack.org (Postfix) with ESMTP id B85F96B0005 for ; Tue, 8 Mar 2016 14:46:28 -0500 (EST) Received: by mail-qg0-f54.google.com with SMTP id y89so22005133qge.2 for ; Tue, 08 Mar 2016 11:46:28 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id d70si4522210qkb.34.2016.03.08.11.46.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Mar 2016 11:46:27 -0800 (PST) From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= Subject: HMM (Heterogeneous Memory Management) Date: Tue, 8 Mar 2016 15:42:53 -0500 Message-Id: <1457469802-11850-1-git-send-email-jglisse@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: Linus Torvalds , joro@8bytes.org, Mel Gorman , "H. Peter Anvin" , Peter Zijlstra , Andrea Arcangeli , Johannes Weiner , Larry Woodman , Rik van Riel , Dave Airlie , Brendan Conoboy , Joe Donohue , Christophe Harle , Duncan Poole , Sherry Cheung , Subhash Gutti , John Hubbard , Mark Hairgrove , Lucien Dunning , Cameron Buschardt , Arvind Gopalakrishnan , Haggai Eran , Shachar Raindel , Liran Liss , Roland Dreier , Ben Sander , Greg Stoner , John Bridgman , Michael Mantor , Paul Blinzer , Leonid Shamis , Laurent Morichetti , Alexander Deucher , Linda Wang , Kevin E Martin , Jeff Law , Or Gerlitz , Sagi Grimberg , "Aneesh Kumar K.V" Last time I spoke with Linus and Andrew, the requirement for getting HMM upstream was having real hardware working with it beside Mellanox (as Mellanox does not use all HMM features), both with closed source driver and open source driver. Work on open source driver is underway, and I anticipate we will get update from NVIDIA and other parties on their efforts and plans shortly. I am re-posting now because I want people to have time to look at HMM again. The open source driver will stay behind close doors until hardware is released. I can however have the upstream maintainer share his progress here if anyone feels the need for that. Other parties such as IBM and Mediatek are also interested in HMM. I expect they will comment on their respective hardware when they can. I hope that HMM can be considered for inclusion upstream soon. This version is virtualy the same as the one since last post (modulo rebase differences). Tree with the patchset: git://people.freedesktop.org/~glisse/linux hmm-v12 branch HMM (HMM (Heterogeneous Memory Management) is an helper layer for device driver, its main features are : - Shadow CPU page table of a process into a device specific format page table and keep both page table synchronize. - Handle DMA mapping of system ram page on behalf of device (for shadowed page table entry). - Migrate private anonymous memory to private device memory and handle CPU page fault (which triggers a migration back to system memory so CPU can access it). Benefits of HMM : - Avoid current model where device driver have to pin page which blocks several kernel features (KSM, migration, ...). - No impact on existing workload that do not use HMM (it only adds couple more if() to common code path). - Intended as common infrastructure for various hardware. - Allow userspace API to move away from explicit copy code path where application programmer has to manage manually memcpy to and from device memory. - Transparent to userspace, for instance allowing library to use GPU without involving application linked against it. Change log : v12: - Rebase v11: - Fix PROT_NONE case - Fix missing page table walk callback - Add support for hugetlbfs v10: - Minor fixes here and there. v9: - Added new device driver helpers. - Added documentions. - Improved page table code claritity (minor architectural changes and better names). v8: - Removed currently unuse fence code. - Added DMA mapping on behalf of device. v7: - Redone and simplified page table code to match Linus suggestion http://article.gmane.org/gmane.linux.kernel.mm/125257 ... Lost in translation ... Why doing this ? Mirroring a process address space is mandatory with OpenCL 2.0 and with other GPU compute APIs. OpenCL 2.0 allows 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 discrete 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 future, discrete GPUs will remain releveant as they can have a large quantity of faster memory than integrated GPU. Thus we believe HMM will allow us to leverage discrete GPUs 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 14. 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 tree allows and we need to store dma address (sizeof(dma_addr_t) > sizeof(long) on some platform). (1) 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/ v8 https://lwn.net/Articles/645515/ v9 https://lwn.net/Articles/651553/ v10 https://lwn.net/Articles/654430/ v11 https://lkml.org/lkml/2015/10/21/739 Cheers, JA(C)rA'me To: "Andrew Morton" , To: , To: linux-mm , Cc: "Linus Torvalds" , Cc: "Mel Gorman" , Cc: "H. Peter Anvin" , Cc: "Peter Zijlstra" , Cc: "Linda Wang" , Cc: "Kevin E Martin" , Cc: "Andrea Arcangeli" , Cc: "Johannes Weiner" , Cc: "Larry Woodman" , Cc: "Rik van Riel" , Cc: "Dave Airlie" , Cc: "Jeff Law" , Cc: "Brendan Conoboy" , Cc: "Joe Donohue" , Cc: "Christophe Harle" , Cc: "Duncan Poole" , Cc: "Sherry Cheung" , Cc: "Subhash Gutti" , Cc: "John Hubbard" , Cc: "Mark Hairgrove" , Cc: "Lucien Dunning" , Cc: "Cameron Buschardt" , Cc: "Arvind Gopalakrishnan" , Cc: "Haggai Eran" , Cc: "Or Gerlitz" , Cc: "Sagi Grimberg" Cc: "Shachar Raindel" , Cc: "Liran Liss" , Cc: "Roland Dreier" , Cc: "Sander, Ben" , Cc: "Stoner, Greg" , Cc: "Bridgman, John" , Cc: "Mantor, Michael" , Cc: "Blinzer, Paul" , Cc: "Morichetti, Laurent" , Cc: "Deucher, Alexander" , Cc: "Leonid Shamis" Cc: "Aneesh Kumar K.V" -- 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: email@kvack.org