Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751625AbdI3Wtd (ORCPT ); Sat, 30 Sep 2017 18:49:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55140 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751202AbdI3Wtb (ORCPT ); Sat, 30 Sep 2017 18:49:31 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A90C1883BA Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jglisse@redhat.com Date: Sat, 30 Sep 2017 18:49:28 -0400 From: Jerome Glisse To: Bob Liu Cc: Bob Liu , Dan Williams , "linux-kernel@vger.kernel.org" , Linux MM , John Hubbard , David Nellans , Balbir Singh , Michal Hocko , Andrew Morton Subject: Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5 Message-ID: <20170930224927.GC6775@redhat.com> References: <20170720150305.GA2767@redhat.com> <20170721014106.GB25991@redhat.com> <20170905193644.GD19397@redhat.com> <20170911233649.GA4892@redhat.com> <20170926161635.GA3216@redhat.com> <0d7273c3-181c-6d68-3c5f-fa518e782374@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0d7273c3-181c-6d68-3c5f-fa518e782374@huawei.com> 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.26]); Sat, 30 Sep 2017 22:49:31 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2951 Lines: 63 On Sat, Sep 30, 2017 at 10:57:38AM +0800, Bob Liu wrote: > On 2017/9/27 0:16, Jerome Glisse wrote: > > On Tue, Sep 26, 2017 at 05:56:26PM +0800, Bob Liu wrote: > >> On Tue, Sep 12, 2017 at 7:36 AM, Jerome Glisse wrote: > >>> On Sun, Sep 10, 2017 at 07:22:58AM +0800, Bob Liu wrote: > >>>> On Wed, Sep 6, 2017 at 3:36 AM, Jerome Glisse wrote: > >>>>> On Thu, Jul 20, 2017 at 08:48:20PM -0700, Dan Williams wrote: > >>>>>> On Thu, Jul 20, 2017 at 6:41 PM, Jerome Glisse wrote: > [...] > >>>>> So i pushed a branch with WIP for nouveau to use HMM: > >>>>> > >>>>> https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-nouveau > >>>>> > >>>> > >>>> Nice to see that. > >>>> Btw, do you have any plan for a CDM-HMM driver? CPU can write to > >>>> Device memory directly without extra copy. > >>> > >>> Yes nouveau CDM support on PPC (which is the only CDM platform commercialy > >>> available today) is on the TODO list. Note that the driver changes for CDM > >>> are minimal (probably less than 100 lines of code). From the driver point > >>> of view this is memory and it doesn't matter if it is CDM or not. > >>> > >> > >> It seems have to migrate/copy memory between system-memory and > >> device-memory even in HMM-CDM solution. > >> Because device-memory is not added into buddy system, the page fault > >> for normal malloc() always allocate memory from system-memory!! > >> If the device then access the same virtual address, the data is copied > >> to device-memory. > >> > >> Correct me if I misunderstand something. > >> @Balbir, how do you plan to make zero-copy work if using HMM-CDM? > > > > Device can access system memory so copy to device is _not_ mandatory. Copying > > data to device is for performance only ie the device driver take hint from > > userspace and monitor device activity to decide which memory should be migrated > > to device memory to maximize performance. > > > > Moreover in some previous version of the HMM patchset we had an helper that > > Could you point in which version? I'd like to have a look. I will need to dig in. > > > allowed to directly allocate device memory on device page fault. I intend to > > post this helper again. With that helper you can have zero copy when device > > is the first to access the memory. > > > > Plan is to get what we have today work properly with the open source driver > > and make it perform well. Once we get some experience with real workload we > > might look into allowing CPU page fault to be directed to device memory but > > at this time i don't think we need this. > > > > For us, we need this feature that CPU page fault can be direct to device memory. > So that don't need to copy data from system memory to device memory. > Do you have any suggestion on the implementation? I'll try to make a prototype patch. Why do you need that ? What is the device and what are the requirement ? J?r?me