Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751272AbdCQQTZ (ORCPT ); Fri, 17 Mar 2017 12:19:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16990 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751116AbdCQQTY (ORCPT ); Fri, 17 Mar 2017 12:19:24 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6548A64A71 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=pass smtp.mailfrom=jglisse@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 6548A64A71 Date: Fri, 17 Mar 2017 11:52:37 -0400 From: Jerome Glisse To: Bob Liu Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, John Hubbard , Naoya Horiguchi , David Nellans Subject: Re: [HMM 00/16] HMM (Heterogeneous Memory Management) v18 Message-ID: <20170317155236.GA7582@redhat.com> References: <1489680335-6594-1-git-send-email-jglisse@redhat.com> <20170316134321.c5cf727c21abf89b7e6708a2@linux-foundation.org> <20170316234950.GA5725@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.7.1 (2016-10-04) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 17 Mar 2017 15:52:42 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1999 Lines: 42 On Fri, Mar 17, 2017 at 04:39:28PM +0800, Bob Liu wrote: > On 2017/3/17 7:49, Jerome Glisse wrote: > > On Thu, Mar 16, 2017 at 01:43:21PM -0700, Andrew Morton wrote: > >> On Thu, 16 Mar 2017 12:05:19 -0400 J__r__me Glisse wrote: > >> > >>> Cliff note: > >> > >> "Cliff's notes" isn't appropriate for a large feature such as this. > >> Where's the long-form description? One which permits readers to fully > >> understand the requirements, design, alternative designs, the > >> implementation, the interface(s), etc? > >> > >> Have you ever spoken about HMM at a conference? If so, the supporting > >> presentation documents might help here. That's the level of detail > >> which should be presented here. > > > > Longer description of patchset rational, motivation and design choices > > were given in the first few posting of the patchset to which i included > > a link in my cover letter. Also given that i presented that for last 3 > > or 4 years to mm summit and kernel summit i thought that by now peoples > > were familiar about the topic and wanted to spare them the long version. > > My bad. > > > > I attach a patch that is a first stab at a Documentation/hmm.txt that > > explain the motivation and rational behind HMM. I can probably add a > > section about how to use HMM from device driver point of view. > > > > And a simple example program/pseudo-code make use of the device memory > would also very useful for person don't have GPU programming experience :) Like i said there is no userspace API to this. Right now it is under driver control what and when to migrate. So this is specific to each driver and without a driver which use this feature nothing happen. Each driver will expose its own API that probably won't be expose to the end user but to the user space driver (OpenCL, Cuda, C++, OpenMP, ...). We are not sure what kind of API we will expose in the nouveau driver this still need to be discuss. Same for the AMD driver. Cheers, J?r?me