Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp802168ybg; Tue, 28 Jul 2020 20:37:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzq7QsBWVpp44PZHgPZLyv0KadDnx3tpOEHJPQIi3IkDD26KXgICNCWK2wKdwNczIPScQEo X-Received: by 2002:aa7:c9c2:: with SMTP id i2mr10454956edt.326.1595993822659; Tue, 28 Jul 2020 20:37:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595993822; cv=none; d=google.com; s=arc-20160816; b=rtghYFTBMZwcoSA6eHM7iNUHF6jXYb/qXEwMJKWmfGOpgTW8cmMFji28hbFXvzHCAK EzfaYb8TXrKp48gXPTZaqga/q5lgdYf24KOxnqpAJVuT/BC2tUTPC+zeTcT/sIMwEKX5 QDyptslX665vXQF1b1ItK6sREaIrCc+3fJOnHYVQEc9h6OJYaJZvCBJlIXR6wqRxkwGp OBFkPZ4G2aPLFRsmh33pjcVaCc2ZDv3B3J122ts3ZUA92WmE1uA2xdO1x55nf6wfi440 tKrYLwGP9Q/At190ilZscjAtgTK82OyDU9sswEIWAcqfsDIwcuqjbdZyhhe5Ns4IHlt6 u/+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=LbZTkb4Wp1a++LipRNJ/XjY0O6Q7dlbf/WCx4jjMAVg=; b=qIuLWd9XFGupEK5AjASD1bgUaA3SFxnzx5Ggwy2VV4rjPSXrITf/V3EYLm3jzIzi/P rSQzRm7dwLnLa8r3P+0g56feCf2Y7IuikIJ888ZNk79+goh7WiGeb+v3lNyqaj2LwLn8 TmM3pKdSNXymnWVN3ayQNVkHEh/Oupiqhh+91oKOt+TOnbk2qpZ4XY1YBnxG9BuXg3Xj 3d8O6ib64jcbDGded8C9BB5vXWjRqBNeKbOKbmi6jiNUfrh6tnQ9Mm8qDxz24nXeST9m cgLBtI/oW+CdNhzbeYqrxF65nEPoZ5fUWtX1aXgiSkHgeAjo+NUNhMvvzh7/MHrRV+o8 IM9A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v1si305794ejd.418.2020.07.28.20.36.40; Tue, 28 Jul 2020 20:37:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726871AbgG2Dfh (ORCPT + 99 others); Tue, 28 Jul 2020 23:35:37 -0400 Received: from foss.arm.com ([217.140.110.172]:44600 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726245AbgG2Dfg (ORCPT ); Tue, 28 Jul 2020 23:35:36 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1CA4631B; Tue, 28 Jul 2020 20:35:36 -0700 (PDT) Received: from localhost.localdomain (entos-thunderx2-02.shanghai.arm.com [10.169.212.213]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id A161E3F66E; Tue, 28 Jul 2020 20:35:28 -0700 (PDT) From: Jia He To: Dan Williams , Vishal Verma , Mike Rapoport , David Hildenbrand Cc: Catalin Marinas , Will Deacon , Greg Kroah-Hartman , "Rafael J. Wysocki" , Dave Jiang , Andrew Morton , Steve Capper , Mark Rutland , Logan Gunthorpe , Anshuman Khandual , Hsin-Yi Wang , Jason Gunthorpe , Dave Hansen , Kees Cook , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-nvdimm@lists.01.org, linux-mm@kvack.org, Wei Yang , Pankaj Gupta , Ira Weiny , Kaly Xin , Jia He Subject: [RFC PATCH 3/6] mm/memory_hotplug: allow pmem kmem not to align with memory_block_size Date: Wed, 29 Jul 2020 11:34:21 +0800 Message-Id: <20200729033424.2629-4-justin.he@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200729033424.2629-1-justin.he@arm.com> References: <20200729033424.2629-1-justin.he@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When dax pmem is probed as RAM device on arm64, previously, kmem_start in dev_dax_kmem_probe() should be aligned with 1G memblock size on arm64 due to SECTION_SIZE_BITS(30). There will be some meta data at the beginning/end of the iomem space, e.g. namespace info and nvdimm label: 240000000-33fdfffff : Persistent Memory 240000000-2403fffff : namespace0.0 280000000-2bfffffff : dax0.0 280000000-2bfffffff : System RAM Hence it makes the whole kmem space not aligned with memory_block_size for both start addr and end addr. Hence there is a big gap when kmem is added into memory block which causes big memory space wasting. This changes it by relaxing the alignment check for dax pmem kmem in the path of online/offline memory blocks. Signed-off-by: Jia He --- drivers/base/memory.c | 16 ++++++++++++++++ mm/memory_hotplug.c | 39 ++++++++++++++++++++++++++++++++++++++- 2 files changed, 54 insertions(+), 1 deletion(-) diff --git a/drivers/base/memory.c b/drivers/base/memory.c index 4a1691664c6c..3d2a94f3b1d9 100644 --- a/drivers/base/memory.c +++ b/drivers/base/memory.c @@ -334,6 +334,22 @@ static ssize_t valid_zones_show(struct device *dev, * online nodes otherwise the page_zone is not reliable */ if (mem->state == MEM_ONLINE) { +#ifdef CONFIG_ZONE_DEVICE + struct resource res; + int ret; + + /* adjust start_pfn for dax pmem kmem */ + ret = find_next_iomem_res(start_pfn << PAGE_SHIFT, + ((start_pfn + nr_pages) << PAGE_SHIFT) - 1, + IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY, + IORES_DESC_PERSISTENT_MEMORY, + false, &res); + if (!ret && PFN_UP(res.start) > start_pfn) { + nr_pages -= PFN_UP(res.start) - start_pfn; + start_pfn = PFN_UP(res.start); + } +#endif + /* * The block contains more than one zone can not be offlined. * This can happen e.g. for ZONE_DMA and ZONE_DMA32 diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index a53103dc292b..25745f67b680 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -999,6 +999,20 @@ int try_online_node(int nid) static int check_hotplug_memory_range(u64 start, u64 size) { +#ifdef CONFIG_ZONE_DEVICE + struct resource res; + int ret; + + /* Allow pmem kmem not to align with block size */ + ret = find_next_iomem_res(start, start + size - 1, + IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY, + IORES_DESC_PERSISTENT_MEMORY, + false, &res); + if (!ret) { + return 0; + } +#endif + /* memory range must be block size aligned */ if (!size || !IS_ALIGNED(start, memory_block_size_bytes()) || !IS_ALIGNED(size, memory_block_size_bytes())) { @@ -1481,19 +1495,42 @@ static int __ref __offline_pages(unsigned long start_pfn, mem_hotplug_begin(); /* - * Don't allow to offline memory blocks that contain holes. + * Don't allow to offline memory blocks that contain holes except + * for pmem. * Consequently, memory blocks with holes can never get onlined * via the hotplug path - online_pages() - as hotplugged memory has * no holes. This way, we e.g., don't have to worry about marking * memory holes PG_reserved, don't need pfn_valid() checks, and can * avoid using walk_system_ram_range() later. + * When dax pmem is used as RAM (kmem), holes at the beginning is + * allowed. */ walk_system_ram_range(start_pfn, end_pfn - start_pfn, &nr_pages, count_system_ram_pages_cb); if (nr_pages != end_pfn - start_pfn) { +#ifdef CONFIG_ZONE_DEVICE + struct resource res; + + /* Allow pmem kmem not to align with block size */ + ret = find_next_iomem_res(start_pfn << PAGE_SHIFT, + (end_pfn << PAGE_SHIFT) - 1, + IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY, + IORES_DESC_PERSISTENT_MEMORY, + false, &res); + if (ret) { + ret = -EINVAL; + reason = "memory holes"; + goto failed_removal; + } + + /* adjust start_pfn for dax pmem kmem */ + start_pfn = PFN_UP(res.start); + end_pfn = PFN_DOWN(res.end + 1); +#else ret = -EINVAL; reason = "memory holes"; goto failed_removal; +#endif } /* This makes hotplug much easier...and readable. -- 2.17.1