Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1300670imu; Thu, 20 Dec 2018 13:49:38 -0800 (PST) X-Google-Smtp-Source: AFSGD/XBgT/OSsVPxuUucykcXw7mQUWQQI4yY1dRo7ZA8aecWDiz5jmn/YzpVxUUVVT3Tlv+bjbL X-Received: by 2002:a63:2054:: with SMTP id r20mr24383032pgm.328.1545342577948; Thu, 20 Dec 2018 13:49:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545342577; cv=none; d=google.com; s=arc-20160816; b=sQHHHj4FvA3fScNmA+fzbZYmn6Qc5oAzawiKpStGDhrRDGlfpqqudTdoM3jwiQK9Xy z2xPMkWHk0GZsRADrltxcTrpgYzBT8vHY36YMUQuMhKYOOnBDuy8MjL4J2qVsf1974s8 fDYXnRUORm1jvnAFRpdsJG9oajSY+Y6PKcQ+HfqsUgvPfGCjZ9MSG3ZPngew80dT0ob/ 90hyuBWJybx75G/l85tIzZJtAYvvcjYCcoZ5L9k33otJ5/NQ6Cj5jIU0rluYiKL0riQs n9OjGm9FPNmLAvMmnfLyE2Xqrfaw24kDqHXHzhkJEP3J7avrJCtwWlnPvXrjbvwUXjgX yKKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=DlRmWxwYkGiemAGOvpjXH8W/zDccdzLTW3jStr0DHgM=; b=L67N8il0scMGVF3wviCsj6Bpvo4+R2DlEdIQmss7OPmsA/5u2ikDkdlnBwfkGMJ4MG VbQyNNCyp1m2hv2FJFHaAYaXQ2VCmmClEXEOIsf8KvweBEYcijfNhmDjgtvJ6N7m/6o0 olcvDmZ1mI7k8jP7yA0dIvkdkENgBp9l8Gdc9atBRvkO03QHnQ02EnKnbg8bBoXkISqs dqqYOO+oOJ9C/hRdqauycdcrssZUJbHOVy+qTQqQDXW7dL/lf0ofX4gTIPg0mjiU0fWB LbB3Me0fuQgSSllKJrgcMdNIDBPS9wY/MfEP8PGwYU1kVeTWViXdumU9EGVff+085TK7 zuhw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k35si19216480pgm.225.2018.12.20.13.49.20; Thu, 20 Dec 2018 13:49:37 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732151AbeLTQPt (ORCPT + 99 others); Thu, 20 Dec 2018 11:15:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45118 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728803AbeLTQPt (ORCPT ); Thu, 20 Dec 2018 11:15:49 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 08F9CA08EF; Thu, 20 Dec 2018 16:15:48 +0000 (UTC) Received: from redhat.com (ovpn-123-95.rdu2.redhat.com [10.10.123.95]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EDF9D6FECC; Thu, 20 Dec 2018 16:15:40 +0000 (UTC) Date: Thu, 20 Dec 2018 11:15:38 -0500 From: Jerome Glisse To: Dan Williams Cc: Andrew Morton , Linux Kernel Mailing List , linux-mm , John Hubbard , David Nellans , Balbir Singh , Ross Zwisler Subject: Re: [HMM-v25 07/19] mm/ZONE_DEVICE: new type of ZONE_DEVICE for unaddressable memory v5 Message-ID: <20181220161538.GA3963@redhat.com> References: <20170817000548.32038-1-jglisse@redhat.com> <20170817000548.32038-8-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.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 20 Dec 2018 16:15:48 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 20, 2018 at 12:33:47AM -0800, Dan Williams wrote: > On Wed, Aug 16, 2017 at 5:06 PM J?r?me Glisse wrote: > > > > HMM (heterogeneous memory management) need struct page to support migration > > from system main memory to device memory. Reasons for HMM and migration to > > device memory is explained with HMM core patch. > > > > This patch deals with device memory that is un-addressable memory (ie CPU > > can not access it). Hence we do not want those struct page to be manage > > like regular memory. That is why we extend ZONE_DEVICE to support different > > types of memory. > > > > A persistent memory type is define for existing user of ZONE_DEVICE and a > > new device un-addressable type is added for the un-addressable memory type. > > There is a clear separation between what is expected from each memory type > > and existing user of ZONE_DEVICE are un-affected by new requirement and new > > use of the un-addressable type. All specific code path are protect with > > test against the memory type. > > > > Because memory is un-addressable we use a new special swap type for when > > a page is migrated to device memory (this reduces the number of maximum > > swap file). > > > > The main two additions beside memory type to ZONE_DEVICE is two callbacks. > > First one, page_free() is call whenever page refcount reach 1 (which means > > the page is free as ZONE_DEVICE page never reach a refcount of 0). This > > allow device driver to manage its memory and associated struct page. > > > > The second callback page_fault() happens when there is a CPU access to > > an address that is back by a device page (which are un-addressable by the > > CPU). This callback is responsible to migrate the page back to system > > main memory. Device driver can not block migration back to system memory, > > HMM make sure that such page can not be pin into device memory. > > > > If device is in some error condition and can not migrate memory back then > > a CPU page fault to device memory should end with SIGBUS. > > > > Changed since v4: > > - s/DEVICE_PUBLIC/DEVICE_HOST (to free DEVICE_PUBLIC for HMM-CDM) > > Changed since v3: > > - fix comments that was still using UNADDRESSABLE as keyword > > - kernel configuration simplification > > Changed since v2: > > - s/DEVICE_UNADDRESSABLE/DEVICE_PRIVATE > > Changed since v1: > > - rename to device private memory (from device unaddressable) > > > > Signed-off-by: J?r?me Glisse > > Acked-by: Dan Williams > > Cc: Ross Zwisler > [..] > > fs/proc/task_mmu.c | 7 +++++ > > include/linux/ioport.h | 1 + > > include/linux/memremap.h | 73 ++++++++++++++++++++++++++++++++++++++++++++++++ > > include/linux/mm.h | 12 ++++++++ > > include/linux/swap.h | 24 ++++++++++++++-- > > include/linux/swapops.h | 68 ++++++++++++++++++++++++++++++++++++++++++++ > > kernel/memremap.c | 34 ++++++++++++++++++++++ > > mm/Kconfig | 11 +++++++- > > mm/memory.c | 61 ++++++++++++++++++++++++++++++++++++++++ > > mm/memory_hotplug.c | 10 +++++-- > > mm/mprotect.c | 14 ++++++++++ > > 11 files changed, 309 insertions(+), 6 deletions(-) > > > [..] > > diff --git a/include/linux/memremap.h b/include/linux/memremap.h > > index 93416196ba64..8e164ec9eed0 100644 > > --- a/include/linux/memremap.h > > +++ b/include/linux/memremap.h > > @@ -4,6 +4,8 @@ > > #include > > #include > > > > +#include > > + > > So it turns out, over a year later, that this include was a mistake > and makes the build fragile. > > > struct resource; > > struct device; > > > [..] > > +typedef int (*dev_page_fault_t)(struct vm_area_struct *vma, > > + unsigned long addr, > > + const struct page *page, > > + unsigned int flags, > > + pmd_t *pmdp); > > I recently included this file somewhere that did not have a pile of > other mm headers included and 0day reports: > > In file included from arch/m68k/include/asm/pgtable_mm.h:148:0, > from arch/m68k/include/asm/pgtable.h:5, > from include/linux/memremap.h:7, > from drivers//dax/bus.c:3: > arch/m68k/include/asm/motorola_pgtable.h: In function 'pgd_offset': > >> arch/m68k/include/asm/motorola_pgtable.h:199:11: error: dereferencing pointer to incomplete type 'const struct mm_struct' > return mm->pgd + pgd_index(address); > ^~ > I assume this pulls in the entirety of pgtable.h just to get the pmd_t > definition? > > > +typedef void (*dev_page_free_t)(struct page *page, void *data); > > + > > /** > > * struct dev_pagemap - metadata for ZONE_DEVICE mappings > > + * @page_fault: callback when CPU fault on an unaddressable device page > > + * @page_free: free page callback when page refcount reaches 1 > > * @altmap: pre-allocated/reserved memory for vmemmap allocations > > * @res: physical address range covered by @ref > > * @ref: reference count that pins the devm_memremap_pages() mapping > > * @dev: host device of the mapping for debug > > + * @data: private data pointer for page_free() > > + * @type: memory type: see MEMORY_* in memory_hotplug.h > > */ > > struct dev_pagemap { > > + dev_page_fault_t page_fault; > > Rather than try to figure out how to forward declare pmd_t, how about > just move dev_page_fault_t out of the generic dev_pagemap and into the > HMM specific container structure? This should be straightfoward on top > of the recent refactor. Fine with me. Cheers, J?r?me