From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751534AbdFGOGe convert rfc822-to-8bit (ORCPT ); Wed, 7 Jun 2017 10:06:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40492 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751467AbdFGOGd (ORCPT ); Wed, 7 Jun 2017 10:06:33 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E698237EE1 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jglisse@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E698237EE1 Date: Wed, 7 Jun 2017 10:06:30 -0400 (EDT) From: Jerome Glisse To: Balbir Singh Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm , Dan Williams , "Kirill A . Shutemov" , John Hubbard , Evgeny Baskakov , Mark Hairgrove , Sherry Cheung , Subhash Gutti Message-ID: <1800115030.31087797.1496844390023.JavaMail.zimbra@redhat.com> In-Reply-To: References: <20170524172024.30810-1-jglisse@redhat.com> <20170524172024.30810-13-jglisse@redhat.com> <20170531135954.1d67ca31@firefly.ozlabs.ibm.com> <20170601223518.GA2780@redhat.com> Subject: Re: [HMM 12/15] mm/migrate: new memory migration helper for use with device memory v4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Originating-IP: [10.10.120.3, 10.4.195.3] Thread-Topic: mm/migrate: new memory migration helper for use with device memory v4 Thread-Index: fXtYhtWN5HW+KHM7WuUhxlMNfMVQSg== X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 07 Jun 2017 14:06:32 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Fri, Jun 2, 2017 at 8:35 AM, Jerome Glisse wrote: > > On Wed, May 31, 2017 at 01:59:54PM +1000, Balbir Singh wrote: > >> On Wed, 24 May 2017 13:20:21 -0400 > >> Jérôme Glisse wrote: > >> > >> > This patch add a new memory migration helpers, which migrate memory > >> > backing a range of virtual address of a process to different memory > >> > (which can be allocated through special allocator). It differs from > >> > numa migration by working on a range of virtual address and thus by > >> > doing migration in chunk that can be large enough to use DMA engine > >> > or special copy offloading engine. > >> > > >> > Expected users are any one with heterogeneous memory where different > >> > memory have different characteristics (latency, bandwidth, ...). As > >> > an example IBM platform with CAPI bus can make use of this feature > >> > to migrate between regular memory and CAPI device memory. New CPU > >> > architecture with a pool of high performance memory not manage as > >> > cache but presented as regular memory (while being faster and with > >> > lower latency than DDR) will also be prime user of this patch. > >> > > >> > Migration to private device memory will be useful for device that > >> > have large pool of such like GPU, NVidia plans to use HMM for that. > >> > > >> > >> It is helpful, for HMM-CDM however we would like to avoid the downsides > >> of MIGRATE_SYNC_NOCOPY > > > > What are the downside you are referring too ? > > IIUC, MIGRATE_SYNC_NO_COPY is for anonymous memory only. It can migrate anything, file back page too. It just forbid that latter case if it is ZONE_DEVICE HMM. I should have time now to finish the CDM patchset and i will post, previous patches already enabled file back page migration for HMM-CDM. The NOCOPY is for no CPUCOPY, i couldn't think of a better name. Cheers, Jérôme From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f200.google.com (mail-qk0-f200.google.com [209.85.220.200]) by kanga.kvack.org (Postfix) with ESMTP id 7362C6B0279 for ; Wed, 7 Jun 2017 10:06:34 -0400 (EDT) Received: by mail-qk0-f200.google.com with SMTP id r62so2361586qkf.6 for ; Wed, 07 Jun 2017 07:06:34 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id h4si1647032qtc.335.2017.06.07.07.06.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 07:06:33 -0700 (PDT) Date: Wed, 7 Jun 2017 10:06:30 -0400 (EDT) From: Jerome Glisse Message-ID: <1800115030.31087797.1496844390023.JavaMail.zimbra@redhat.com> In-Reply-To: References: <20170524172024.30810-1-jglisse@redhat.com> <20170524172024.30810-13-jglisse@redhat.com> <20170531135954.1d67ca31@firefly.ozlabs.ibm.com> <20170601223518.GA2780@redhat.com> Subject: Re: [HMM 12/15] mm/migrate: new memory migration helper for use with device memory v4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: Balbir Singh Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm , Dan Williams , "Kirill A . Shutemov" , John Hubbard , Evgeny Baskakov , Mark Hairgrove , Sherry Cheung , Subhash Gutti > On Fri, Jun 2, 2017 at 8:35 AM, Jerome Glisse wrote: > > On Wed, May 31, 2017 at 01:59:54PM +1000, Balbir Singh wrote: > >> On Wed, 24 May 2017 13:20:21 -0400 > >> J=C3=A9r=C3=B4me Glisse wrote: > >> > >> > This patch add a new memory migration helpers, which migrate memory > >> > backing a range of virtual address of a process to different memory > >> > (which can be allocated through special allocator). It differs from > >> > numa migration by working on a range of virtual address and thus by > >> > doing migration in chunk that can be large enough to use DMA engine > >> > or special copy offloading engine. > >> > > >> > Expected users are any one with heterogeneous memory where different > >> > memory have different characteristics (latency, bandwidth, ...). As > >> > an example IBM platform with CAPI bus can make use of this feature > >> > to migrate between regular memory and CAPI device memory. New CPU > >> > architecture with a pool of high performance memory not manage as > >> > cache but presented as regular memory (while being faster and with > >> > lower latency than DDR) will also be prime user of this patch. > >> > > >> > Migration to private device memory will be useful for device that > >> > have large pool of such like GPU, NVidia plans to use HMM for that. > >> > > >> > >> It is helpful, for HMM-CDM however we would like to avoid the downside= s > >> of MIGRATE_SYNC_NOCOPY > > > > What are the downside you are referring too ? >=20 > IIUC, MIGRATE_SYNC_NO_COPY is for anonymous memory only. It can migrate anything, file back page too. It just forbid that latter case if it is ZONE_DEVICE HMM. I should have time now to finish the CDM patchset and i will post, previous patches already enabled file back page migration for HMM-CDM. The NOCOPY is for no CPUCOPY, i couldn't think of a better name. Cheers, J=C3=A9r=C3=B4me -- 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