Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934282AbcJZQHc (ORCPT ); Wed, 26 Oct 2016 12:07:32 -0400 Received: from mail-qk0-f193.google.com ([209.85.220.193]:36076 "EHLO mail-qk0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933352AbcJZQHa (ORCPT ); Wed, 26 Oct 2016 12:07:30 -0400 Date: Wed, 26 Oct 2016 12:07:21 -0400 From: Jerome Glisse To: "Aneesh Kumar K.V" Cc: Anshuman Khandual , linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@suse.com, js1304@gmail.com, vbabka@suse.cz, mgorman@suse.de, minchan@kernel.org, akpm@linux-foundation.org, bsingharora@gmail.com Subject: Re: [RFC 0/8] Define coherent device memory node Message-ID: <20161026160721.GA13638@gmail.com> References: <1477283517-2504-1-git-send-email-khandual@linux.vnet.ibm.com> <20161024170902.GA5521@gmail.com> <87a8dtawas.fsf@linux.vnet.ibm.com> <20161025151637.GA6072@gmail.com> <87y41bcqow.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87y41bcqow.fsf@linux.vnet.ibm.com> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1239 Lines: 28 On Wed, Oct 26, 2016 at 04:39:19PM +0530, Aneesh Kumar K.V wrote: > Jerome Glisse writes: > > > On Tue, Oct 25, 2016 at 09:56:35AM +0530, Aneesh Kumar K.V wrote: > >> Jerome Glisse writes: > >> > >> > On Mon, Oct 24, 2016 at 10:01:49AM +0530, Anshuman Khandual wrote: > >> > > >> I looked at the hmm-v13 w.r.t migration and I guess some form of device > >> callback/acceleration during migration is something we should definitely > >> have. I still haven't figured out how non addressable and coherent device > >> memory can fit together there. I was waiting for the page cache > >> migration support to be pushed to the repository before I start looking > >> at this closely. > >> > > > > The page cache migration does not touch the migrate code path. My issue with > > page cache is writeback. The only difference with existing migrate code is > > refcount check for ZONE_DEVICE page. Everything else is the same. > > What about the radix tree ? does file system migrate_page callback handle > replacing normal page with ZONE_DEVICE page/exceptional entries ? > It use the exact same existing code (from mm/migrate.c) so yes the radix tree is updated and buffer_head are migrated. J?r?me