From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754646AbdFWP3D (ORCPT ); Fri, 23 Jun 2017 11:29:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59220 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754616AbdFWP2x (ORCPT ); Fri, 23 Jun 2017 11:28:53 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 460E04E4D1 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jglisse@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 460E04E4D1 Date: Fri, 23 Jun 2017 11:28:50 -0400 From: Jerome Glisse To: Bob Liu Cc: Andrew Morton , Linux-Kernel , Linux-MM , Dan Williams , "Kirill A . Shutemov" , John Hubbard Subject: Re: [HMM 00/15] HMM (Heterogeneous Memory Management) v23 Message-ID: <20170623152849.GA3128@redhat.com> References: <20170524172024.30810-1-jglisse@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 23 Jun 2017 15:28:53 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 23, 2017 at 11:00:37PM +0800, Bob Liu wrote: > Hi, > > On Thu, May 25, 2017 at 1:20 AM, Jérôme Glisse wrote: > > Patchset is on top of git://git.cmpxchg.org/linux-mmotm.git so i > > test same kernel as kbuild system, git branch: > > > > https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-v23 > > > > Change since v22 is use of static key for special ZONE_DEVICE case in > > put_page() and build fix for architecture with no mmu. > > > > Everything else is the same. Below is the long description of what HMM > > is about and why. At the end of this email i describe briefly each patch > > and suggest reviewers for each of them. > > > > > > Heterogeneous Memory Management (HMM) (description and justification) > > > > Today device driver expose dedicated memory allocation API through their > > device file, often relying on a combination of IOCTL and mmap calls. The > > device can only access and use memory allocated through this API. This > > effectively split the program address space into object allocated for the > > device and useable by the device and other regular memory (malloc, mmap > > of a file, share memory, â) only accessible by CPU (or in a very limited > > way by a device by pinning memory). > > > > Allowing different isolated component of a program to use a device thus > > require duplication of the input data structure using device memory > > allocator. This is reasonable for simple data structure (array, grid, > > image, â) but this get extremely complex with advance data structure > > (list, tree, graph, â) that rely on a web of memory pointers. This is > > becoming a serious limitation on the kind of work load that can be > > offloaded to device like GPU. > > > > New industry standard like C++, OpenCL or CUDA are pushing to remove this > > barrier. This require a shared address space between GPU device and CPU so > > that GPU can access any memory of a process (while still obeying memory > > protection like read only). This kind of feature is also appearing in > > various other operating systems. > > > > HMM is a set of helpers to facilitate several aspects of address space > > sharing and device memory management. Unlike existing sharing mechanism > > It looks like the address space sharing and device memory management > are two different things. They don't depend on each other and HMM has > helpers for both. > > Is it possible to separate these two things into two patchsets? > Which will make it's more easy to review and also follow the "Do one > thing, and do it well" philosophy. > They are already seperate. Patch 3-5 are for address space mirroring. Patch 6-10 for device memory using struct page and ZONE_DEVICE. Finaly patch 11-15 for adding new page migration helper capable of using device DMA engine to perform memory copy operation. Patch 1 is just common documentation and patch 2 is common helpers and definitions. Also they are separate at kernel configuration level. So for all intents and purposes this is already 2 separate things, just in one posting because first user will use both. You can use one without the other and it will work properly. Cheers, Jérôme