From patchwork Thu Mar 3 21:32:48 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joao Martins X-Patchwork-Id: 12768177 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 260AFC433F5 for ; Thu, 3 Mar 2022 21:33:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 232418D0003; Thu, 3 Mar 2022 16:33:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E35B8D0001; Thu, 3 Mar 2022 16:33:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 033528D0003; Thu, 3 Mar 2022 16:33:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id E8F718D0001 for ; Thu, 3 Mar 2022 16:33:46 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B9FFB2312 for ; Thu, 3 Mar 2022 21:33:46 +0000 (UTC) X-FDA: 79204377252.03.3E31993 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf14.hostedemail.com (Postfix) with ESMTP id E46BB100004 for ; Thu, 3 Mar 2022 21:33:45 +0000 (UTC) Received: from pps.filterd (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 223KEmBd028284; Thu, 3 Mar 2022 21:33:33 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : content-type : mime-version; s=corp-2021-07-09; bh=tSZQk7HtTV6HKgfK4W2uW+38Fl91pLiEqT8Zv3n42NA=; b=NNi3mXIfA4E8z6zW7TaVUoJ26jalqyNnK53VZpPXQly4JBIkfuMwjbIxWsFYHBrWYRb0 LUBrF1hLMAHr+vNN4N7WZnnEjt7O92klKR/gD0t7EOI2pjpyy+UvbL40jJq/uQ9ducT3 SgV5boN26xE7s8xThDK3dXja7CvneAr07YohrsJsroyQgI6aWTYkxNbNmEgnKkdVFn73 c0h9y4XmWG4A0/pLmx1nQUlqUCZA8+AXa8hB0WJ+UtSPjbAfiCexXCIQLnAmvNbAEiWm +y0Ml1/Ax96n0dYDq9yS+gHWKZ+xwL9SGtP32psOsc/JBXGcIdf7KxZZfGHD4J/ImN/E Tw== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by mx0b-00069f02.pphosted.com with ESMTP id 3ek4hw05h7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 03 Mar 2022 21:33:33 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.1.2/8.16.1.2) with SMTP id 223LKtL4132075; Thu, 3 Mar 2022 21:33:32 GMT Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2049.outbound.protection.outlook.com [104.47.66.49]) by aserp3020.oracle.com with ESMTP id 3ek4j7tpuw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 03 Mar 2022 21:33:32 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UC83XilLr3JKBezPskIKDKJLxFJ8HYwm/pNNZku636vxcbpe/emlereXT6LjiYpyCmXV/rdnh58aO7EuDrwAnyPq+q8y+wbHGXWjUVIow4T5I6QMyly302nMos1oizs+NVWxAvpEyNMSRMW714CPoIpsh9e8dBaPYmKf3cNqN1cuPL7XU+MyJ3tGCGKidicx/faYl8RgjlORqg/aMv+pee2nLN/V5UFH9OjRymLVxvnvpMb6QU6DCRK5Qy44XHLZIM8IgPtIrGPRO5Ym8YLoA9WkIm9dvMzx+E6vGkVcGpOuSZ3duj5h6XdXLC+xv8A+kE0AVfVnGOvq1+0QjuuUzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tSZQk7HtTV6HKgfK4W2uW+38Fl91pLiEqT8Zv3n42NA=; b=l6llHqq3TR0uENX3LSo8dUHVVNkjsfNiQt2RQeRBYxxomnZWaoGG259nZR4YBX/NfQa9V32IOaEo5YE8CksOfs6gk9OqGFiMTIud4G0Ik6HCWyNuA6K9kqPbK0EYdDi/HrIkUVSxqSBK5+ETv548r/2HWk9HdV3c2HsR6gGQnzNLrljOJ+rVSFCYlo1KZiqaEKie4T7KapHDKCWBZ3rxoLXpIrad+jmCe8Ehr67YCfL/0bF3LAhu8ybeBARfb3uD1mF5My5SnU5bRAtmCz5diV8jkruu3YZ+lEBgSnRJdcHt6c2NklqfpaVU8TtMUyrgb0vd1L3jPHLTHWGmUrKklA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tSZQk7HtTV6HKgfK4W2uW+38Fl91pLiEqT8Zv3n42NA=; b=vMAIx0v9hKMb7sf3YzznjNNJ9asKanXkYoKzFuX3CdcVEOBUknu0vL2BbgAQSfvKDfp5gTwT6SOIAMZSrzkWhFei5YA8s9LfG07KQOWRT5v/mSNovofe5q39FOYqn8t42gRRhGHFzEIeTm0NwPhjeH9tKRfPFseJ75GrEWxcQNw= Received: from BLAPR10MB4835.namprd10.prod.outlook.com (2603:10b6:208:331::11) by DM5PR10MB1658.namprd10.prod.outlook.com (2603:10b6:4:4::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.15; Thu, 3 Mar 2022 21:33:28 +0000 Received: from BLAPR10MB4835.namprd10.prod.outlook.com ([fe80::750f:bf1d:1599:3406]) by BLAPR10MB4835.namprd10.prod.outlook.com ([fe80::750f:bf1d:1599:3406%5]) with mapi id 15.20.5038.014; Thu, 3 Mar 2022 21:33:27 +0000 From: Joao Martins To: linux-mm@kvack.org Cc: Dan Williams , Vishal Verma , Matthew Wilcox , Jason Gunthorpe , Jane Chu , Muchun Song , Mike Kravetz , Andrew Morton , Jonathan Corbet , Christoph Hellwig , nvdimm@lists.linux.dev, linux-doc@vger.kernel.org, Joao Martins Subject: [PATCH v7 1/5] mm/sparse-vmemmap: add a pgmap argument to section activation Date: Thu, 3 Mar 2022 21:32:48 +0000 Message-Id: <20220303213252.28593-2-joao.m.martins@oracle.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20220303213252.28593-1-joao.m.martins@oracle.com> References: <20220303213252.28593-1-joao.m.martins@oracle.com> X-ClientProxiedBy: LO4P123CA0036.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:151::23) To BLAPR10MB4835.namprd10.prod.outlook.com (2603:10b6:208:331::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e1f52846-fc26-4da8-2609-08d9fd5d7427 X-MS-TrafficTypeDiagnostic: DM5PR10MB1658:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: qbnyFD1uoeG9mglRwqYyWpfL7023H4os2BBZcQSVLMYzFJsMKpbOM0rK8r4OVglD96oWzzGGNM9OLjyj0mn8LcByPNKnYE65HuQzTB5SkMJtqmfBW9DlmLxfLtNIxrOWRYap7hSyYD+G1XJxXWnwFkuvA/j1rCdjp63SQnA88aThOIQMtvEFHEbjDMKsaRVTttLtCfTZvMzbVoaZM9yP6PmhAv3H1sv7dSiFPFv9kDi5YVPI/9Ivh9ObF1g8aFkmlGfyzs0WIKNzVqAHMrHCbpsfApySGKq7YL2T+p39VLFhyzjoBjp8StaLTzyA8ND0Lr4U0C16Zpu65ZPfEe2hNaXs8c2yR7Ot6aAN7UEzNZ0Ussxb6JTiIoLTU7hfOLDPe3zuOLREPRDFyzpZFI1T5r3xQcEH0M/Ec2bc7GBJuSE4LYRldrZosuMyBL5KtXbFMThbB25bXNaUsr5c9i47mewveZ1zPyyTvzUserlgKnpxu9HgTBR6QiQd9wTBA8sSA45EO9+kgvCWeTZbTjEoyJIwaQrukzsTOFburCRYNp8+fgm4EUHSxol2UvSf8IVXCbblWqfozOM3JjrXaIn8FSBo+VJ7ltwQgkThvDMTpLaYuxeYnKAOjahNimMHDOklBD5l9wTkrSgjgnhTDY2EHaLBSHC1O/GVALpYcujkwGezVnAcRT4xHJBS71qBnvZSFBrfSeKi3oURvxd5Qimh9tvCfum8sT5w6P1TDjGCH1eWX4A/SmMSplRVUHpZp0oaPlnUfvmR30H86TwYON1/4zZu632cx+LCa39/y/xUq6E= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BLAPR10MB4835.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230001)(366004)(83380400001)(38100700002)(38350700002)(186003)(107886003)(26005)(1076003)(5660300002)(36756003)(103116003)(2906002)(7416002)(8936002)(66946007)(508600001)(66556008)(86362001)(966005)(6486002)(66476007)(6512007)(52116002)(316002)(2616005)(8676002)(4326008)(6916009)(6506007)(6666004)(54906003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: h8rc6vZYYy8swO25dBiv8su5NejdHehnleGw7H0FDsJF6EwIdF0JUaabWyOiIrmqtNhNFRq4e6ogkqYnEpgNZD88d/kvQIVVEo+sgwFkrRbg44b1w2wh5JWaT7ChBZhiUvuyuE8Ea7JiTZDVWHubjI2/UznqzNU+Zbao+ry/JGhFXfWt405+B/Zyq+kkN9viT1vaO+RKKWuBC72BmyOMHnBXWTIPEqAuyiPWO7VtuWm4qoXZRVKGEIIGwNGKk1Yr0YY5HywW4R7tZfFN4kckwGD6KCCFmcdTxmKO4m0y927Fn+QorHBNhp1gYatPP5zg37EtR08jy8VLO/R/oypFnh36b+R83S1HBzgxVYMpFEW7YpntpZecawj0iZ7mG6HxVTYCfmbK/LhRnGPEcZxOrhmonj6sX4fhjNlpezjaotwV3f6akM60od95lh58D57uNK3xqO0OM8zZLl2jVVpFw1mes/IA6fA9fvD+6CCkCLq991nToRsHFYCUn1a6VSTqwuCWyw/YONKAqxS9CX08QBFBQkobWw3b+EghD1J7iOIigNSuRdvtpDMB6Y7n5wJScIWdqyHJgHf02bEj5X3rgy6gpeChR4/d4SFUXnZsDvFNSnxdAK0KblxWNBvjUL6i9qKsq8l9paWs1istBdDb4jF2jrM+DPmWsylC6CqQjcuKLNdeZnmXvNgcmcoDSLKXC4CHcg8PWMyWm9+I1iNeSLN4eu+r9fqe0nMP6cipuxmNOFhx1xrESeNy8LHbPy1u1wqHJ9UgIlAmpJ1sJ8D64K6etz1Ja2a3P2MBRBj1hbOqjxXsx7Ue8eUPm+MDfFP5aDLvOgoW8jSKXuTbNyPHsjTHEhzLY+aqaz0dtABJmt/ge+HaQ/cWQpraH1uHUn/YaMY7nGWepmFQo+NWMn+j3IOvIxVSnWsV4DddNq5jSPD5jja8KGBtUUMu7SprNLQeboMlwux3be4cuGFl2QUwTvRWhCGHHoKdyWxIXZ6yYJ5NL2Fqo+rT4lg9PhTVUD2NRavLCAQocyWIqLv0cgzmOcYrSix6cs/OJB+MLNo46vf9dycV6S/1NYVcPdSWR9C3KHsTs3GH/TSd/h9HjkI4OHoJpYW3BXOAA1oIl4+7/FHz64e1OCmDbOfcMUuIZgvqQTEn9bsVDLxZd0e3tzDHgwzLjPja+988+QnbshCME+o0LUCn5fXoBseDyfiefoxjpL9OkOkH3B06z1H4o8b+DEkdePyv9xcdaEC0oJ6dJnMfcPgyhuWyUonenAyTbT8+av/gS6hPZMPeHdt/EhcS9w22sZ3gX2ZNHYhzYXjle/DlrgYgkFVsCb3J9uZ0fFmH4eVQ5s4/n8VA41Zq3+gd37sPv9bOgV3IUsEuf3Mz7xvSBR9QswCaQxOSumdQNnnN3MOUxBBnIp4ZVMtoWaVOvvnvCGclX/88p0ZoAryRvF7461kZUDt2DAdzgWLJE3rpcAPJftOTK97cJBWOn5Tb1mxC6qsBZuFKd4jMPQY30oQXPu4GEJPE2CiMCk2svYBowWeN4eNUE4rfTtIGLOqZCjhTJn4k6CqGzqnbEFDqdlAddNQ8QzOjMuOX+/YwBAqAb8KDGS2ABH71nh+g5t+xPHoEncTPyYBjvc/CaEQGx+dHFiuoVCZIbmmv0jlJiUloXxUNLMVPhP3XN4JqhaT3ZA== X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: e1f52846-fc26-4da8-2609-08d9fd5d7427 X-MS-Exchange-CrossTenant-AuthSource: BLAPR10MB4835.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2022 21:33:27.8080 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: j+lmIZJjXRozyc11pSVaMXCmfho1KEMygCA1yu2kq6BXrfBAA90G7N5v81zxe3Hj4QZte2UfeRSR880V461ODZyrQw/NzeH4vAJzvR3HNfs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR10MB1658 X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10275 signatures=686983 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 bulkscore=0 malwarescore=0 mlxscore=0 spamscore=0 suspectscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203030097 X-Proofpoint-ORIG-GUID: BovjFyJCuuIEa2U4vJc4ofjv6QjiMz6x X-Proofpoint-GUID: BovjFyJCuuIEa2U4vJc4ofjv6QjiMz6x X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: E46BB100004 X-Rspam-User: Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2021-07-09 header.b=NNi3mXIf; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=vMAIx0v9; spf=none (imf14.hostedemail.com: domain of joao.m.martins@oracle.com has no SPF policy when checking 205.220.165.32) smtp.mailfrom=joao.m.martins@oracle.com; dmarc=pass (policy=none) header.from=oracle.com X-Stat-Signature: 6def158te8ip6378zju3io6766fpyqye X-HE-Tag: 1646343225-564362 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: In support of using compound pages for devmap mappings, plumb the pgmap down to the vmemmap_populate implementation. Note that while altmap is retrievable from pgmap the memory hotplug code passes altmap without pgmap[*], so both need to be independently plumbed. So in addition to @altmap, pass @pgmap to sparse section populate functions namely: sparse_add_section section_activate populate_section_memmap __populate_section_memmap Passing @pgmap allows __populate_section_memmap() to both fetch the vmemmap_shift in which memmap metadata is created for and also to let sparse-vmemmap fetch pgmap ranges to co-relate to a given section and pick whether to just reuse tail pages from past onlined sections. While at it, fix the kdoc for @altmap for sparse_add_section(). [*] https://lore.kernel.org/linux-mm/20210319092635.6214-1-osalvador@suse.de/ Signed-off-by: Joao Martins Reviewed-by: Dan Williams Reviewed-by: Muchun Song --- include/linux/memory_hotplug.h | 5 ++++- include/linux/mm.h | 3 ++- mm/memory_hotplug.c | 3 ++- mm/sparse-vmemmap.c | 3 ++- mm/sparse.c | 26 ++++++++++++++++---------- 5 files changed, 26 insertions(+), 14 deletions(-) diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h index 1ce6f8044f1e..e0b2209ab71c 100644 --- a/include/linux/memory_hotplug.h +++ b/include/linux/memory_hotplug.h @@ -15,6 +15,7 @@ struct memory_block; struct memory_group; struct resource; struct vmem_altmap; +struct dev_pagemap; #ifdef CONFIG_HAVE_ARCH_NODEDATA_EXTENSION /* @@ -122,6 +123,7 @@ typedef int __bitwise mhp_t; struct mhp_params { struct vmem_altmap *altmap; pgprot_t pgprot; + struct dev_pagemap *pgmap; }; bool mhp_range_allowed(u64 start, u64 size, bool need_mapping); @@ -333,7 +335,8 @@ extern void remove_pfn_range_from_zone(struct zone *zone, unsigned long nr_pages); extern bool is_memblock_offlined(struct memory_block *mem); extern int sparse_add_section(int nid, unsigned long pfn, - unsigned long nr_pages, struct vmem_altmap *altmap); + unsigned long nr_pages, struct vmem_altmap *altmap, + struct dev_pagemap *pgmap); extern void sparse_remove_section(struct mem_section *ms, unsigned long pfn, unsigned long nr_pages, unsigned long map_offset, struct vmem_altmap *altmap); diff --git a/include/linux/mm.h b/include/linux/mm.h index 49692a64d645..5f549cf6a4e8 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -3111,7 +3111,8 @@ int vmemmap_remap_alloc(unsigned long start, unsigned long end, void *sparse_buffer_alloc(unsigned long size); struct page * __populate_section_memmap(unsigned long pfn, - unsigned long nr_pages, int nid, struct vmem_altmap *altmap); + unsigned long nr_pages, int nid, struct vmem_altmap *altmap, + struct dev_pagemap *pgmap); pgd_t *vmemmap_pgd_populate(unsigned long addr, int node); p4d_t *vmemmap_p4d_populate(pgd_t *pgd, unsigned long addr, int node); pud_t *vmemmap_pud_populate(p4d_t *p4d, unsigned long addr, int node); diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index aee69281dad6..2cc1c49a2be6 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -328,7 +328,8 @@ int __ref __add_pages(int nid, unsigned long pfn, unsigned long nr_pages, /* Select all remaining pages up to the next section boundary */ cur_nr_pages = min(end_pfn - pfn, SECTION_ALIGN_UP(pfn + 1) - pfn); - err = sparse_add_section(nid, pfn, cur_nr_pages, altmap); + err = sparse_add_section(nid, pfn, cur_nr_pages, altmap, + params->pgmap); if (err) break; cond_resched(); diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c index 8aecd6b3896c..c506f77cff23 100644 --- a/mm/sparse-vmemmap.c +++ b/mm/sparse-vmemmap.c @@ -641,7 +641,8 @@ int __meminit vmemmap_populate_basepages(unsigned long start, unsigned long end, } struct page * __meminit __populate_section_memmap(unsigned long pfn, - unsigned long nr_pages, int nid, struct vmem_altmap *altmap) + unsigned long nr_pages, int nid, struct vmem_altmap *altmap, + struct dev_pagemap *pgmap) { unsigned long start = (unsigned long) pfn_to_page(pfn); unsigned long end = start + nr_pages * sizeof(struct page); diff --git a/mm/sparse.c b/mm/sparse.c index 952f06d8f373..d2d76d158b39 100644 --- a/mm/sparse.c +++ b/mm/sparse.c @@ -427,7 +427,8 @@ static unsigned long __init section_map_size(void) } struct page __init *__populate_section_memmap(unsigned long pfn, - unsigned long nr_pages, int nid, struct vmem_altmap *altmap) + unsigned long nr_pages, int nid, struct vmem_altmap *altmap, + struct dev_pagemap *pgmap) { unsigned long size = section_map_size(); struct page *map = sparse_buffer_alloc(size); @@ -524,7 +525,7 @@ static void __init sparse_init_nid(int nid, unsigned long pnum_begin, break; map = __populate_section_memmap(pfn, PAGES_PER_SECTION, - nid, NULL); + nid, NULL, NULL); if (!map) { pr_err("%s: node[%d] memory map backing failed. Some memory will not be available.", __func__, nid); @@ -629,9 +630,10 @@ void offline_mem_sections(unsigned long start_pfn, unsigned long end_pfn) #ifdef CONFIG_SPARSEMEM_VMEMMAP static struct page * __meminit populate_section_memmap(unsigned long pfn, - unsigned long nr_pages, int nid, struct vmem_altmap *altmap) + unsigned long nr_pages, int nid, struct vmem_altmap *altmap, + struct dev_pagemap *pgmap) { - return __populate_section_memmap(pfn, nr_pages, nid, altmap); + return __populate_section_memmap(pfn, nr_pages, nid, altmap, pgmap); } static void depopulate_section_memmap(unsigned long pfn, unsigned long nr_pages, @@ -700,7 +702,8 @@ static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages) } #else struct page * __meminit populate_section_memmap(unsigned long pfn, - unsigned long nr_pages, int nid, struct vmem_altmap *altmap) + unsigned long nr_pages, int nid, struct vmem_altmap *altmap, + struct dev_pagemap *pgmap) { return kvmalloc_node(array_size(sizeof(struct page), PAGES_PER_SECTION), GFP_KERNEL, nid); @@ -823,7 +826,8 @@ static void section_deactivate(unsigned long pfn, unsigned long nr_pages, } static struct page * __meminit section_activate(int nid, unsigned long pfn, - unsigned long nr_pages, struct vmem_altmap *altmap) + unsigned long nr_pages, struct vmem_altmap *altmap, + struct dev_pagemap *pgmap) { struct mem_section *ms = __pfn_to_section(pfn); struct mem_section_usage *usage = NULL; @@ -855,7 +859,7 @@ static struct page * __meminit section_activate(int nid, unsigned long pfn, if (nr_pages < PAGES_PER_SECTION && early_section(ms)) return pfn_to_page(pfn); - memmap = populate_section_memmap(pfn, nr_pages, nid, altmap); + memmap = populate_section_memmap(pfn, nr_pages, nid, altmap, pgmap); if (!memmap) { section_deactivate(pfn, nr_pages, altmap); return ERR_PTR(-ENOMEM); @@ -869,7 +873,8 @@ static struct page * __meminit section_activate(int nid, unsigned long pfn, * @nid: The node to add section on * @start_pfn: start pfn of the memory range * @nr_pages: number of pfns to add in the section - * @altmap: device page map + * @altmap: alternate pfns to allocate the memmap backing store + * @pgmap: alternate compound page geometry for devmap mappings * * This is only intended for hotplug. * @@ -883,7 +888,8 @@ static struct page * __meminit section_activate(int nid, unsigned long pfn, * * -ENOMEM - Out of memory. */ int __meminit sparse_add_section(int nid, unsigned long start_pfn, - unsigned long nr_pages, struct vmem_altmap *altmap) + unsigned long nr_pages, struct vmem_altmap *altmap, + struct dev_pagemap *pgmap) { unsigned long section_nr = pfn_to_section_nr(start_pfn); struct mem_section *ms; @@ -894,7 +900,7 @@ int __meminit sparse_add_section(int nid, unsigned long start_pfn, if (ret < 0) return ret; - memmap = section_activate(nid, start_pfn, nr_pages, altmap); + memmap = section_activate(nid, start_pfn, nr_pages, altmap, pgmap); if (IS_ERR(memmap)) return PTR_ERR(memmap); From patchwork Thu Mar 3 21:32:49 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joao Martins X-Patchwork-Id: 12768178 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id CCE05C433EF for ; Thu, 3 Mar 2022 21:33:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 31DA68D0005; Thu, 3 Mar 2022 16:33:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2A6518D0001; Thu, 3 Mar 2022 16:33:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB6F98D0005; Thu, 3 Mar 2022 16:33:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0112.hostedemail.com [216.40.44.112]) by kanga.kvack.org (Postfix) with ESMTP id D3CB68D0001 for ; Thu, 3 Mar 2022 16:33:47 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 93A84181B566F for ; Thu, 3 Mar 2022 21:33:47 +0000 (UTC) X-FDA: 79204377294.17.57F06D1 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by imf24.hostedemail.com (Postfix) with ESMTP id DD385180014 for ; Thu, 3 Mar 2022 21:33:46 +0000 (UTC) Received: from pps.filterd (m0246631.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 223KEb2w031267; Thu, 3 Mar 2022 21:33:34 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : content-type : mime-version; s=corp-2021-07-09; bh=1YUEoTnh1aGzrXHHQVADdNm+TBpzs27JjOXaNE3VmQU=; b=zEVQK6ZYH0cCSGzHwYztwXM0GzC53OCLoiYPFCAozmPJxPcchOS9YaCJP39yXsn6Jnl3 vrJ+fiYOiYdWfdMVRthG1CzTpESHkmS5mJSlFSAcmYkGYjLGeKbHD+tytg55+yQyHUfb YLseRC/+AX8dQVmfn5Oe/Y0NkF0drkKd/U683WlCM/0ORwhx8jGs2Dpnor20b875ogon GYwMOU/u/VhQpUR5yxikzrq/liA5hWUjc5IjtmjcaOJf0XskC0A7vEfh1Y5PR8YsaVpJ 4Oe5jpnVUcO+HdCHex2JeqT7PYsG/+ZLuoAmHiRQ3cIR1Jeo38b7DLAv/cxTrxIxSZ6J ew== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by mx0b-00069f02.pphosted.com with ESMTP id 3ek4ht05dh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 03 Mar 2022 21:33:33 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.1.2/8.16.1.2) with SMTP id 223LKtL5132075; Thu, 3 Mar 2022 21:33:33 GMT Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2049.outbound.protection.outlook.com [104.47.66.49]) by aserp3020.oracle.com with ESMTP id 3ek4j7tpuw-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 03 Mar 2022 21:33:32 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=asOo3hA7Kfxzrlu4oPjFcmH6hllu/8Xkz8TZ53vX125GUjX5rcOquAOtpJscixCGH+6snhj8j8+gAUVLzMpQM+/uyUOSOO/1zobJjJUQkwnIiCSblcQYzJb3UQRfMxg57UZ7rjD8T4JIU7pA3zrbtwk8K7SDg1zeMItFOYiwi1Ouv+4ss2/rM7kUAUMIGPgcz4bPWAcrvCurFuKN/8UH9ireC6ZCH79tghwFBE4cw2cXYHuy//tvu8HETFrm04E114JO4NgxV6OyThwfSgAtm8J85tZxmA8ulNLuuf1oLV827BXDn2AmTypwFbX9LuRE8dktIrbZmcSmyoZ3o7O4yQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1YUEoTnh1aGzrXHHQVADdNm+TBpzs27JjOXaNE3VmQU=; b=JWxj2SIllBIm7Nw/Mqnsty6MP/gmWB7Etr+CwhgwqZnHgwIkGDbHuYV2TRmME2aDaY6mQ0t+mqElgVyHJ51fbx8yXGIaltI81WUXqyH1TMDx1AgfhovTdZYWTzikemE+SU5/IiosLdWORpUUgZR9reDg5PL1XJkmHYHPRVfSFsUvJx4WUyVsicxmcPko0EhU0nmh9N26c3aby63yUwn6dCirjx/Fi2NarL7aC33XGtmENkTZ+Qo+G9s7ya6mj/XjrEbde43289x5u1OYiw0BMQkVjwO09CqfulDHTEuF7J7RwhADJKtHBYSslf9cP2VvZthBxMsBXn70wDMBVqhw6A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1YUEoTnh1aGzrXHHQVADdNm+TBpzs27JjOXaNE3VmQU=; b=S33goalYhay2wF2yMWvxtykE12WXc9Cd6BDeAr9745x1qQsHxBknQ4VBQRL3iNAv2AU88DRthDSKqGOQsihTlxof91AX50NapU8XdmsDtPSGqSUl2ziXs63awrgkb/YT9VHqErOaGnPGyfnqMoxe5mmCj3i+MngsO1+TVmNcVCw= Received: from BLAPR10MB4835.namprd10.prod.outlook.com (2603:10b6:208:331::11) by DM5PR10MB1658.namprd10.prod.outlook.com (2603:10b6:4:4::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.15; Thu, 3 Mar 2022 21:33:30 +0000 Received: from BLAPR10MB4835.namprd10.prod.outlook.com ([fe80::750f:bf1d:1599:3406]) by BLAPR10MB4835.namprd10.prod.outlook.com ([fe80::750f:bf1d:1599:3406%5]) with mapi id 15.20.5038.014; Thu, 3 Mar 2022 21:33:30 +0000 From: Joao Martins To: linux-mm@kvack.org Cc: Dan Williams , Vishal Verma , Matthew Wilcox , Jason Gunthorpe , Jane Chu , Muchun Song , Mike Kravetz , Andrew Morton , Jonathan Corbet , Christoph Hellwig , nvdimm@lists.linux.dev, linux-doc@vger.kernel.org, Joao Martins Subject: [PATCH v7 2/5] mm/sparse-vmemmap: refactor core of vmemmap_populate_basepages() to helper Date: Thu, 3 Mar 2022 21:32:49 +0000 Message-Id: <20220303213252.28593-3-joao.m.martins@oracle.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20220303213252.28593-1-joao.m.martins@oracle.com> References: <20220303213252.28593-1-joao.m.martins@oracle.com> X-ClientProxiedBy: LO4P123CA0036.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:151::23) To BLAPR10MB4835.namprd10.prod.outlook.com (2603:10b6:208:331::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6ad35acc-e3f6-4efb-a37a-08d9fd5d75d6 X-MS-TrafficTypeDiagnostic: DM5PR10MB1658:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 0MpJ5wMYcU4MmEgCHq848PRoEdQkG37pcdoNf8tek7YGt35hP5wF2qAEC6U+NwrRA04BJ4atBi/YXDg3Gt/f/dgo3AAmIWejx6DGGyL1APqxQg6pt4kH81lH+pRNA4LyS+zJEO9mpdT40aGLcg4HQ3lYIA1XGwctzp6LjUir9jtIcPCZubH0B7+ucTCopJJ5SXx/9GqSHztjYJSar6aTi2wwJkdRpy/AnyEVWOnJ5IfVmYEv0hlwh7u4SNn0RRSSL/RF911m7fAa56gBNbEGEutCij9gorF0QYhg9pzwtpTJgR0T+Z7yG00/4ulZZy52aSnCIHbxma8y/9LQa2SwT6Lm4oAnbf4A8KQvqsKlmMdmgrBvyKTnkUpg4NiGMNa0z1xNVDL8sQZwrZVsolDQLFENBGmm6oHSvrkSjRnXNa/NAhu4QoJux16p4KdjvqKYKax/1HlStWkX1f7/l1XT/O3fl7shAFmu9TGfW1sJRTRdKQ9SiZ741D/M60fXBCuGfcCeI/8BuspKqVazQcv5DVoJxVeXRDCCTSGAv2+1Gdv4q1q1l+BJ4hAp33kGrCRGbKE8S9reT0DaRlvhEi1MJPSxNG0TwIqACUMQrauwgHa1ZUIV/St1kxjszemW48IVcVTkuJIoxXWy2piiqBoUdYuINOZDoyhKYanTLOD6N2cgX74Qx3Bei6mwN3dDwEoqmqC2yTINcfnfQq7tIaQvSw== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BLAPR10MB4835.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230001)(366004)(83380400001)(38100700002)(38350700002)(186003)(107886003)(26005)(1076003)(5660300002)(36756003)(103116003)(2906002)(7416002)(8936002)(66946007)(508600001)(66556008)(86362001)(6486002)(66476007)(6512007)(52116002)(316002)(2616005)(8676002)(4326008)(6916009)(6506007)(6666004)(54906003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: v8aSljQqnuOti+aR3Uzl5uzL8rgIxFM38qVqebReof/0rv5Gh8CkvSmGmalTVnX9b7R4Rw419QVUasHiEtK+pi2kyXvjLhLX4Oqc672PRqFAn3kgxyubQBaj6guLOmbSuiiKWRPRyeoDP1BkUGHI2aRB5+hgkZX1b1eifL+4oOd1Ar8o1LaNKMcghr/cNY8VkidOMilOlIJuuNc11/aFtME4qLgFis5s7TNNknoK3Qs5MnmD4tVpaXJh//nLrBWFNdta23twT5GAqYmdA6muhMazayUje+Gb41l1TDrtRIRDCfoIN1x4NSvR0CIwPI8yXiO6qPVn+Y8IUTsHZ+XvZ9HB+OZqZSjaFRbBLyb78Izt4bjb2LPD0iSby89+rwx6j9R6JG3SrkNc4vL/PxG3eKVDXAoCBtm8/o1T8lzBqUAxW+04xhZ4vSzdBOeDWXD4TlfG5E6h8Tfq/nu7uuNUnN0BzgAgDBZ8kFAeYDQm3qA0g6aTyYYHa6Aa791L/p3b9VgdFhLcHTwYaQgc7rZBJGMHpcZZL5Gw+j6FVOz0LGleujX5k3PsUhPDXBahK1l6vxWrCk2rmoZgJGg5ZDo6N4yo9IfAJ/AUKvfvxHzGquGfk8UN9zPPQ0W7XKcNj3txj6ZZ+X5CLnriDgfsAHxKRxS2KA7t5t9edsbN+ai/4R1dPXtveny46njKJjhwi/EMvC3h40acebOWBVRI9rS3vFKh/0gJol8G3AJAZoKFwwstzHLuEN/G7XP5JXKdocq+ffIYRV1zwa8b1pfo7TKLNhFGJVw/94sh695ViEur/RX8/kfbkw0ovljUDDSsdE5YmHwpaygAWYgDH3kzZpw3QoOHfCzebQMc4q5RCe6FSzuV9gQkhDIVy4REvjK9jIKMNeihjrRp4KmAflXOV5m8JW6Pzi7vjbUAbM0lVgTyqUjOrNlU+4dGMFQ3t9UiUnXOBLkQQ40LKgZfk1TaaraF3B6qZjLDri4cY/grrk7/y08uaZoL8gKvel44bAs1PeV8C8SBUSsWQsXABuB1okL0+CinMw1NMGVkgO5aMtCTZ6QnKDuk2/GmxsGnc/HcjDgIa5otNLLjWG9G7TVKtnNhWKSwLPvuoPAz0wc7Kd3hMvCgCFzX4BZn4ChFs1Rdjxr5VFLcO6lFHEVAnrmNzeLrjygaOQbjkzSTPDS8Ic0Vrc7ztD6L5sCFszdy9gUT74fmIc/3xLq/dlE4zg552j+ROI8IBKR9uNe3Z67iSjFdTlPQfmYQdPsZVhLnx72ljex23uTjrzD62bhEqRiHRddpExEj2fFoGKmvrwumZzjBCED/bP3lr3deso7Tv775VNkaXAAwSoAwI3DLa0Ucpt7ZDoiXoi4W4BFhdd3T8KrmJqn4jEfSu7j9CfAJHeBTy1EE9x1woX8tb77F40BhWhDgWv/R+cuYEX1XPAPzcuIS0Jv3Nor3uuNvmzm+ItHW2HJj0U1cC/5Xm5pI3/COTZavOf4qNZU6ABxKTqV7ttuvgKs1fxaq3jYSsPKntQawvguXdRfR94kb7uZAQvd3ruYaBiO3E3NmfB6KjqKrkidbUjWoBRR7Pu7BrXmyI6YBdD56fbO//vh8JUhZiyYNS4C+BwWvqt3r+RNt3ZfT7ya2b0/uASAk5HJabX8qvXZYTvKbEv0WLGV54Q1NjQPtlAMtdw== X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6ad35acc-e3f6-4efb-a37a-08d9fd5d75d6 X-MS-Exchange-CrossTenant-AuthSource: BLAPR10MB4835.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2022 21:33:30.5265 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 2VOe+vBA6kpFK+vM4i5uXuzio8YKNcRudZFj1sd0vdKMnQJXggIV30RRD9zJRC46mDbX8P1CKK1ba+F5XuU0IT45dfZl3aB9Qwdow5M+ycc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR10MB1658 X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10275 signatures=686983 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 bulkscore=0 malwarescore=0 mlxscore=0 spamscore=0 suspectscore=0 mlxlogscore=844 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203030097 X-Proofpoint-ORIG-GUID: wDv9F4bZyoW_LGTL2FJQWVckmh4NANmL X-Proofpoint-GUID: wDv9F4bZyoW_LGTL2FJQWVckmh4NANmL X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: DD385180014 X-Stat-Signature: 45eomn9g4o5d5nchtt5gxeji47jnh9ds Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2021-07-09 header.b=zEVQK6ZY; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=S33goalY; spf=none (imf24.hostedemail.com: domain of joao.m.martins@oracle.com has no SPF policy when checking 205.220.177.32) smtp.mailfrom=joao.m.martins@oracle.com; dmarc=pass (policy=none) header.from=oracle.com X-Rspam-User: X-HE-Tag: 1646343226-317444 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: In preparation for describing a memmap with compound pages, move the actual pte population logic into a separate function vmemmap_populate_address() and have a new helper vmemmap_populate_range() walk through all base pages it needs to populate. While doing that, change the helper to use a pte_t* as return value, rather than an hardcoded errno of 0 or -ENOMEM. Signed-off-by: Joao Martins Reviewed-by: Muchun Song --- mm/sparse-vmemmap.c | 53 ++++++++++++++++++++++++++++++--------------- 1 file changed, 36 insertions(+), 17 deletions(-) diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c index c506f77cff23..1b30a82f285e 100644 --- a/mm/sparse-vmemmap.c +++ b/mm/sparse-vmemmap.c @@ -608,38 +608,57 @@ pgd_t * __meminit vmemmap_pgd_populate(unsigned long addr, int node) return pgd; } -int __meminit vmemmap_populate_basepages(unsigned long start, unsigned long end, - int node, struct vmem_altmap *altmap) +static pte_t * __meminit vmemmap_populate_address(unsigned long addr, int node, + struct vmem_altmap *altmap) { - unsigned long addr = start; pgd_t *pgd; p4d_t *p4d; pud_t *pud; pmd_t *pmd; pte_t *pte; + pgd = vmemmap_pgd_populate(addr, node); + if (!pgd) + return NULL; + p4d = vmemmap_p4d_populate(pgd, addr, node); + if (!p4d) + return NULL; + pud = vmemmap_pud_populate(p4d, addr, node); + if (!pud) + return NULL; + pmd = vmemmap_pmd_populate(pud, addr, node); + if (!pmd) + return NULL; + pte = vmemmap_pte_populate(pmd, addr, node, altmap); + if (!pte) + return NULL; + vmemmap_verify(pte, node, addr, addr + PAGE_SIZE); + + return pte; +} + +static int __meminit vmemmap_populate_range(unsigned long start, + unsigned long end, int node, + struct vmem_altmap *altmap) +{ + unsigned long addr = start; + pte_t *pte; + for (; addr < end; addr += PAGE_SIZE) { - pgd = vmemmap_pgd_populate(addr, node); - if (!pgd) - return -ENOMEM; - p4d = vmemmap_p4d_populate(pgd, addr, node); - if (!p4d) - return -ENOMEM; - pud = vmemmap_pud_populate(p4d, addr, node); - if (!pud) - return -ENOMEM; - pmd = vmemmap_pmd_populate(pud, addr, node); - if (!pmd) - return -ENOMEM; - pte = vmemmap_pte_populate(pmd, addr, node, altmap); + pte = vmemmap_populate_address(addr, node, altmap); if (!pte) return -ENOMEM; - vmemmap_verify(pte, node, addr, addr + PAGE_SIZE); } return 0; } +int __meminit vmemmap_populate_basepages(unsigned long start, unsigned long end, + int node, struct vmem_altmap *altmap) +{ + return vmemmap_populate_range(start, end, node, altmap); +} + struct page * __meminit __populate_section_memmap(unsigned long pfn, unsigned long nr_pages, int nid, struct vmem_altmap *altmap, struct dev_pagemap *pgmap) From patchwork Thu Mar 3 21:32:50 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joao Martins X-Patchwork-Id: 12768180 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A6ED3C433FE for ; Thu, 3 Mar 2022 21:33:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 408318D0008; Thu, 3 Mar 2022 16:33:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 369998D0007; Thu, 3 Mar 2022 16:33:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0FBBE8D0008; Thu, 3 Mar 2022 16:33:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0223.hostedemail.com [216.40.44.223]) by kanga.kvack.org (Postfix) with ESMTP id E103D8D0001 for ; Thu, 3 Mar 2022 16:33:48 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 964A8181B566F for ; Thu, 3 Mar 2022 21:33:48 +0000 (UTC) X-FDA: 79204377336.30.FF38A22 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf04.hostedemail.com (Postfix) with ESMTP id C4E5C40007 for ; Thu, 3 Mar 2022 21:33:47 +0000 (UTC) Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 223KEiiR017342; Thu, 3 Mar 2022 21:33:38 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : content-type : mime-version; s=corp-2021-07-09; bh=rBZFKXBhUVcGaQee2IQyxW+Dj+TwY1lOwgsfsaR1Dgs=; b=xNy3M0JCiVHPKx/2RF2Uxyj73Bmrdc6ti89CNWqoEs3Km6Ww/FWHY14Wt90tdNqnX4h5 LwhjD0AEbbAHVw+27X61B2fRYagFIvpCRY2YJ4YYOsZbqH8r3s1AxDAGBKQWVHn0akYY SxK/WUb4qePa5o5aL+9zh3W4dU/Sk38iP+l9mfWfTcmSPivnnNS6QD1RP5wzawsvlEic lPX+eKZgTRPCJ2DhlH+GMUVygH06y5kniZtb73UlKilS2lmDwAVSpCY6BJRHMMFMKqoc VAAAPUO4iBcUiI/eIHFXlKeL7zz3Songg79pv7IwQJJCSUw+1CxgZSIqv5Rr1ke8+TmR 6Q== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by mx0b-00069f02.pphosted.com with ESMTP id 3ek4hvg5he-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 03 Mar 2022 21:33:37 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.1.2/8.16.1.2) with SMTP id 223LKt7t132037; Thu, 3 Mar 2022 21:33:36 GMT Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2043.outbound.protection.outlook.com [104.47.66.43]) by aserp3020.oracle.com with ESMTP id 3ek4j7tq0p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 03 Mar 2022 21:33:36 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KQO4eoY8cy7l4PtWBaRTVn6HC73z06n54n7+jkEGncf5eBtO5gbZbGJh/0b989Rj8vT4ItuyyDeFH4TrEYQetj2hRkqS5aW51StO95I3LAZeYi2XbP4duXmoHP7YTg8wgfP0W3OEudiNrdQ/m63/mvV8ZwUG+16+i8Mq7NPf08sSK1ebh7N1e3FqWaeIg2ZLBfKHKYT125IkJYan8hoe/4YjWHwdGiAYavkOzA1WNYQWMYFOP8OHcGFhYex//p+fLjUaMCR7VRGo8F9mJ3L5dfmPAKfAicnUR5dRCS/tWmZKKhPSyvjEwO0cYCV7zvIdLDz1mS61nBmF0J5s7PttTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rBZFKXBhUVcGaQee2IQyxW+Dj+TwY1lOwgsfsaR1Dgs=; b=JlQJg5LQkfn/tmOkuRkTR3rR8crf/HEdIML6qQTy3kyyOaTQwI4uFmZXNmTUWe40+uQBk7U1G9Fv32+ea1Ws4DckYWLurBnSidjUtOuk+swX6ZdWakrCJJtL0YBOQp+7pkPglGEQZDS4UzBV2gbX+uOuJHGXbs23nfSKY3KJNQjWsn7f1u9PrUMTue+2N1fg7kKCI80wIcxZKiBx7Km7iyBGHYOMsrc4hE89RDo8ehormBtVfNWZlJHvM4CkhCyLEYklcsEQjm4lkTCt2xi9rQhE6VOygewD1kN6D5XqUtFV70iOAe1FmQ3+y8Uv/jK6azc5SmiOwW5TrSBNLTUjxg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rBZFKXBhUVcGaQee2IQyxW+Dj+TwY1lOwgsfsaR1Dgs=; b=rWWKBh2R2j/yNpfMd2AkAAw92yCyewetcpCdNxoMua61UHPn88UDlkPxTScGaljc6C8JvmJI3b5THeYjyaU0dG4K2Z5SErbLBgeF0QyrLRlLT/7QYYC/t6AOp5wtCYUj7S+dvwmS1HwlPf/ecpYS0RbbywI7PgQrxvDiT1TbfuM= Received: from BLAPR10MB4835.namprd10.prod.outlook.com (2603:10b6:208:331::11) by DM5PR10MB1658.namprd10.prod.outlook.com (2603:10b6:4:4::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.15; Thu, 3 Mar 2022 21:33:33 +0000 Received: from BLAPR10MB4835.namprd10.prod.outlook.com ([fe80::750f:bf1d:1599:3406]) by BLAPR10MB4835.namprd10.prod.outlook.com ([fe80::750f:bf1d:1599:3406%5]) with mapi id 15.20.5038.014; Thu, 3 Mar 2022 21:33:33 +0000 From: Joao Martins To: linux-mm@kvack.org Cc: Dan Williams , Vishal Verma , Matthew Wilcox , Jason Gunthorpe , Jane Chu , Muchun Song , Mike Kravetz , Andrew Morton , Jonathan Corbet , Christoph Hellwig , nvdimm@lists.linux.dev, linux-doc@vger.kernel.org, Joao Martins Subject: [PATCH v7 3/5] mm/hugetlb_vmemmap: move comment block to Documentation/vm Date: Thu, 3 Mar 2022 21:32:50 +0000 Message-Id: <20220303213252.28593-4-joao.m.martins@oracle.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20220303213252.28593-1-joao.m.martins@oracle.com> References: <20220303213252.28593-1-joao.m.martins@oracle.com> X-ClientProxiedBy: LO4P123CA0036.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:151::23) To BLAPR10MB4835.namprd10.prod.outlook.com (2603:10b6:208:331::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: dbd7606d-25c3-4711-7778-08d9fd5d7786 X-MS-TrafficTypeDiagnostic: DM5PR10MB1658:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: nO4Y0BLWHDwDCycdjn4BKtTrazwfLcquRCo0Vb21dN5ARjY60tKYQM0UodRv+YbnpgfBY3IdeV+Yqx1eZP+ESTpe7LQe0lEXNAN2g2B36zgQsRVdkvtKl+xIgW3i5Kedi4y29zjcqEHdtk/D/3M6LxCqGwKkh2jV6PH9Gm36ymxrq4sKkwP1rhgt60hCiC1wIjYrSeopG/rTO3iOUrvfd3V98MRk+zhqmfv4JvRvd5u0+TIl/BFk3kP5QI5pvS8U4hrZFCaJg9iIv462NWsDqDlfXwu82AN1GSijyD3JUMVByzb5/qcgoCEHpFZq9BICoKkEB+R5sMs0kA4yGPFju+07KkqH9DPoB97gOsG8re/ehE2h++qqyn0QXQlgXVd23LgkQqPw3FS4FGctUL1WPpLctR9sTKVmt2mTAkEegfXfmYnnh+web2dsL3+YNrPZ4lN8O/iiLkpCkd0vAjSIOb2v1badRsZvjZzp++zryj8ehEnh8x+9zbcGx/iYD43Cgc7unT7ezgliz9BQoA/AMcwHb1Y2mgeytm2lScHoeflk3lTJP3Roo6WczNDhSJBHciNKmfDFXXDbDWKtb6zzvBrcG6oxr+v8FqBY1j0RuX6GuOPG566S8qLx1E80Z0c9z9aBOxqqCZA6Qd3UytFxI5y+Br17ZcM+dbXiXkOKhi1cKimtYtcXBmn+vD/E/87LaczO0QS7FmguarUPDgRp4A== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BLAPR10MB4835.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230001)(366004)(83380400001)(38100700002)(38350700002)(186003)(107886003)(26005)(1076003)(5660300002)(36756003)(30864003)(103116003)(2906002)(7416002)(8936002)(66946007)(508600001)(66556008)(86362001)(6486002)(66476007)(6512007)(52116002)(316002)(2616005)(8676002)(4326008)(6916009)(6506007)(6666004)(54906003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: FXz9jlfDX+zIcQUm/DdaPYjqqff5un6GF0zii5BMQUrcC0hGxro+kJNef7NZqnQWWQ87hP0QURpVE+TiGlXDHAs3GCBOYtaqdBG6i5EvaV2v7gp6fMkBh5LDGFclQCBIzXbLvh/EV6WSHT3OoX1AQFZENpAu13EW3RyISHDS1WkJGqCRTn4df8SJQArxYHR35UewbA9ZPPPDrUqopsywFUZ18iR/SknA4hiWcrDx4laQxzLxJ+MD0avkZzXL0J5ZFOX5U8AWAF16COeJ82e14FBmlCBEkTG6byoZu4opvYEyAxZwcgtvEF1l/hKWn+ZJXSV29KUW1jmH/3k3OgWVmuZc99AdmSRcVYE3DR/g6AIgn5H+FpqXiLzdDwYXwc044QmnSWUgEoulLZIYUfClS/DJ+dRuVjsSBnGNvVBgS2tYfNAuFff4tEKMsF50Mnj+JaTToWmephVUpjrT4jejdMI5qKHsM6QLMIyTiwyH0FF79mJ6ueVj5SXb38qkSanHGBmoPr0i8qrFeG0uKtMmx87j7a5aDQ+8DpdJA3JZB4u1Elo9z3fYZ3yJR5ayh8r5p3rg5csYuB3VuArQ416e5GjAvcWN1A5/rSeH6pXKAdA1J69JSXUpuUz9cj6wOZMxOi6FCIsSYia/SpIOX+rgnSps4GwR/5ScQzMiRaS5K7gFYPq4Atd9AeZv8EnTor1CdJIqWci/taXJXdPWkUZxiHNnRtPfUASAC2h9O6CYh8dYNRrRgbOMQlMTWoherhYyx+N3W/Z8CG2k1xsRdQ0lc/HzquvQXmLg6KqrAMMCS7FxG6Yg6VaX8oklPbLlUni9UEKeHzrcsmLmtMaQMbV99rwun53OzjdH2kvHrcg4Qqk3lmPXDljO/bZFHmMPuXuqHmXEKiswPbzJcyUC60IJo8avUajprHCv5N7di65DeU1Ht5nDzblBMOrXsmY59TyC596obTW57VdzwJIQjhqU2TPA4ICr5RJIcTDCvEizLXvrFhyk16S283FmPEdpxo3pT9wpHFcRXnqUd4tx5QI6k0YO6dgSUUqvjkWg/DfqcdhfP7XZvU/embzggp7kgDRTuW3c75mlRQCND8/CN9cuYPUedjoyjonm6IXiL+XceBOdW7FKA068Sur0tvLRliVkeCMzrnAA4HDYK5vJOPAcXR8H6PDCCi0iKJabXrvnRHffREQh827djswP6JxYeQBiNyaJQkuiIthSxUOg4OiT7MeRo2E+tF84gJIcC5NN6gbLd6MaMtL83AzRSnIL08+gYddv73wpSEgJL1Krz14agd0NViYYh+QgtNTpjy1c1BLaUfl6DtNCFpRo0HyVcQuggJxXRTEgyQK8XbcK4GUK9tT2hcoDjd0tw9yavCGacSRRMk83nYZrLbeZ5D+/ZyXqhE2vZxpUtyLHxUgmoHAOYJNARJLt3iqHl7WbPip++pyoZUY7v8fXj6NJWeEMhG6R9voC8dhMq4gVEb/rTjPoI1B9qvBgb3m97RM6ejkrdPnoA8l1CN798TaBH3yhoAJuAweI1hvhhVyU77GLG7Reo7Bciyth78OtZOJtPLd3h57q3gqOF8tGbSz4lXUU5pHC1fC6UGoCP1l2HO+ctOmX++/ZZ8KA/8ZprC9x5QwhgYYwyglXYsM9eN03FK48d1X71J6J8EKnQvV15gibeb1L6Q== X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: dbd7606d-25c3-4711-7778-08d9fd5d7786 X-MS-Exchange-CrossTenant-AuthSource: BLAPR10MB4835.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2022 21:33:33.5609 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Fn/F79bXU568ilnQMnsNjB1EUa8E+uQdqtyiqWVaLb40nUKV6ORaL+NA21BEwgBF0Z0jDKOZ4NZMPwfztYMdR54VF6PuWBF3LcXxbxroTGQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR10MB1658 X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10275 signatures=686983 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 bulkscore=0 malwarescore=0 mlxscore=0 spamscore=0 suspectscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203030097 X-Proofpoint-ORIG-GUID: TVvnuv77LhZc0zyZUCXTqIM8NtaSYQ7i X-Proofpoint-GUID: TVvnuv77LhZc0zyZUCXTqIM8NtaSYQ7i X-Rspamd-Queue-Id: C4E5C40007 X-Stat-Signature: 5csgfjepa5ecc16438pzcg5g9incnckx X-Rspam-User: Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2021-07-09 header.b=xNy3M0JC; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=rWWKBh2R; dmarc=pass (policy=none) header.from=oracle.com; spf=none (imf04.hostedemail.com: domain of joao.m.martins@oracle.com has no SPF policy when checking 205.220.165.32) smtp.mailfrom=joao.m.martins@oracle.com X-Rspamd-Server: rspam03 X-HE-Tag: 1646343227-22425 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: In preparation for device-dax for using hugetlbfs compound page tail deduplication technique, move the comment block explanation into a common place in Documentation/vm. Cc: Muchun Song Cc: Mike Kravetz Suggested-by: Dan Williams Signed-off-by: Joao Martins Reviewed-by: Muchun Song Reviewed-by: Dan Williams --- Documentation/vm/index.rst | 1 + Documentation/vm/vmemmap_dedup.rst | 175 +++++++++++++++++++++++++++++ mm/hugetlb_vmemmap.c | 168 +-------------------------- 3 files changed, 177 insertions(+), 167 deletions(-) create mode 100644 Documentation/vm/vmemmap_dedup.rst diff --git a/Documentation/vm/index.rst b/Documentation/vm/index.rst index 44365c4574a3..2fb612bb72c9 100644 --- a/Documentation/vm/index.rst +++ b/Documentation/vm/index.rst @@ -37,5 +37,6 @@ algorithms. If you are looking for advice on simply allocating memory, see the transhuge unevictable-lru vmalloced-kernel-stacks + vmemmap_dedup z3fold zsmalloc diff --git a/Documentation/vm/vmemmap_dedup.rst b/Documentation/vm/vmemmap_dedup.rst new file mode 100644 index 000000000000..8143b2ce414d --- /dev/null +++ b/Documentation/vm/vmemmap_dedup.rst @@ -0,0 +1,175 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _vmemmap_dedup: + +================================== +Free some vmemmap pages of HugeTLB +================================== + +The struct page structures (page structs) are used to describe a physical +page frame. By default, there is a one-to-one mapping from a page frame to +it's corresponding page struct. + +HugeTLB pages consist of multiple base page size pages and is supported by +many architectures. See hugetlbpage.rst in the Documentation directory for +more details. On the x86-64 architecture, HugeTLB pages of size 2MB and 1GB +are currently supported. Since the base page size on x86 is 4KB, a 2MB +HugeTLB page consists of 512 base pages and a 1GB HugeTLB page consists of +4096 base pages. For each base page, there is a corresponding page struct. + +Within the HugeTLB subsystem, only the first 4 page structs are used to +contain unique information about a HugeTLB page. __NR_USED_SUBPAGE provides +this upper limit. The only 'useful' information in the remaining page structs +is the compound_head field, and this field is the same for all tail pages. + +By removing redundant page structs for HugeTLB pages, memory can be returned +to the buddy allocator for other uses. + +Different architectures support different HugeTLB pages. For example, the +following table is the HugeTLB page size supported by x86 and arm64 +architectures. Because arm64 supports 4k, 16k, and 64k base pages and +supports contiguous entries, so it supports many kinds of sizes of HugeTLB +page. + ++--------------+-----------+-----------------------------------------------+ +| Architecture | Page Size | HugeTLB Page Size | ++--------------+-----------+-----------+-----------+-----------+-----------+ +| x86-64 | 4KB | 2MB | 1GB | | | ++--------------+-----------+-----------+-----------+-----------+-----------+ +| | 4KB | 64KB | 2MB | 32MB | 1GB | +| +-----------+-----------+-----------+-----------+-----------+ +| arm64 | 16KB | 2MB | 32MB | 1GB | | +| +-----------+-----------+-----------+-----------+-----------+ +| | 64KB | 2MB | 512MB | 16GB | | ++--------------+-----------+-----------+-----------+-----------+-----------+ + +When the system boot up, every HugeTLB page has more than one struct page +structs which size is (unit: pages): + + struct_size = HugeTLB_Size / PAGE_SIZE * sizeof(struct page) / PAGE_SIZE + +Where HugeTLB_Size is the size of the HugeTLB page. We know that the size +of the HugeTLB page is always n times PAGE_SIZE. So we can get the following +relationship. + + HugeTLB_Size = n * PAGE_SIZE + +Then, + + struct_size = n * PAGE_SIZE / PAGE_SIZE * sizeof(struct page) / PAGE_SIZE + = n * sizeof(struct page) / PAGE_SIZE + +We can use huge mapping at the pud/pmd level for the HugeTLB page. + +For the HugeTLB page of the pmd level mapping, then + + struct_size = n * sizeof(struct page) / PAGE_SIZE + = PAGE_SIZE / sizeof(pte_t) * sizeof(struct page) / PAGE_SIZE + = sizeof(struct page) / sizeof(pte_t) + = 64 / 8 + = 8 (pages) + +Where n is how many pte entries which one page can contains. So the value of +n is (PAGE_SIZE / sizeof(pte_t)). + +This optimization only supports 64-bit system, so the value of sizeof(pte_t) +is 8. And this optimization also applicable only when the size of struct page +is a power of two. In most cases, the size of struct page is 64 bytes (e.g. +x86-64 and arm64). So if we use pmd level mapping for a HugeTLB page, the +size of struct page structs of it is 8 page frames which size depends on the +size of the base page. + +For the HugeTLB page of the pud level mapping, then + + struct_size = PAGE_SIZE / sizeof(pmd_t) * struct_size(pmd) + = PAGE_SIZE / 8 * 8 (pages) + = PAGE_SIZE (pages) + +Where the struct_size(pmd) is the size of the struct page structs of a +HugeTLB page of the pmd level mapping. + +E.g.: A 2MB HugeTLB page on x86_64 consists in 8 page frames while 1GB +HugeTLB page consists in 4096. + +Next, we take the pmd level mapping of the HugeTLB page as an example to +show the internal implementation of this optimization. There are 8 pages +struct page structs associated with a HugeTLB page which is pmd mapped. + +Here is how things look before optimization. + + HugeTLB struct pages(8 pages) page frame(8 pages) + +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+ + | | | 0 | -------------> | 0 | + | | +-----------+ +-----------+ + | | | 1 | -------------> | 1 | + | | +-----------+ +-----------+ + | | | 2 | -------------> | 2 | + | | +-----------+ +-----------+ + | | | 3 | -------------> | 3 | + | | +-----------+ +-----------+ + | | | 4 | -------------> | 4 | + | PMD | +-----------+ +-----------+ + | level | | 5 | -------------> | 5 | + | mapping | +-----------+ +-----------+ + | | | 6 | -------------> | 6 | + | | +-----------+ +-----------+ + | | | 7 | -------------> | 7 | + | | +-----------+ +-----------+ + | | + | | + | | + +-----------+ + +The value of page->compound_head is the same for all tail pages. The first +page of page structs (page 0) associated with the HugeTLB page contains the 4 +page structs necessary to describe the HugeTLB. The only use of the remaining +pages of page structs (page 1 to page 7) is to point to page->compound_head. +Therefore, we can remap pages 1 to 7 to page 0. Only 1 page of page structs +will be used for each HugeTLB page. This will allow us to free the remaining +7 pages to the buddy allocator. + +Here is how things look after remapping. + + HugeTLB struct pages(8 pages) page frame(8 pages) + +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+ + | | | 0 | -------------> | 0 | + | | +-----------+ +-----------+ + | | | 1 | ---------------^ ^ ^ ^ ^ ^ ^ + | | +-----------+ | | | | | | + | | | 2 | -----------------+ | | | | | + | | +-----------+ | | | | | + | | | 3 | -------------------+ | | | | + | | +-----------+ | | | | + | | | 4 | ---------------------+ | | | + | PMD | +-----------+ | | | + | level | | 5 | -----------------------+ | | + | mapping | +-----------+ | | + | | | 6 | -------------------------+ | + | | +-----------+ | + | | | 7 | ---------------------------+ + | | +-----------+ + | | + | | + | | + +-----------+ + +When a HugeTLB is freed to the buddy system, we should allocate 7 pages for +vmemmap pages and restore the previous mapping relationship. + +For the HugeTLB page of the pud level mapping. It is similar to the former. +We also can use this approach to free (PAGE_SIZE - 1) vmemmap pages. + +Apart from the HugeTLB page of the pmd/pud level mapping, some architectures +(e.g. aarch64) provides a contiguous bit in the translation table entries +that hints to the MMU to indicate that it is one of a contiguous set of +entries that can be cached in a single TLB entry. + +The contiguous bit is used to increase the mapping size at the pmd and pte +(last) level. So this type of HugeTLB page can be optimized only when its +size of the struct page structs is greater than 1 page. + +Notice: The head vmemmap page is not freed to the buddy allocator and all +tail vmemmap pages are mapped to the head vmemmap page frame. So we can see +more than one struct page struct with PG_head (e.g. 8 per 2 MB HugeTLB page) +associated with each HugeTLB page. The compound_head() can handle this +correctly (more details refer to the comment above compound_head()). diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c index 791626983c2e..dbaa837b19c6 100644 --- a/mm/hugetlb_vmemmap.c +++ b/mm/hugetlb_vmemmap.c @@ -6,173 +6,7 @@ * * Author: Muchun Song * - * The struct page structures (page structs) are used to describe a physical - * page frame. By default, there is a one-to-one mapping from a page frame to - * it's corresponding page struct. - * - * HugeTLB pages consist of multiple base page size pages and is supported by - * many architectures. See hugetlbpage.rst in the Documentation directory for - * more details. On the x86-64 architecture, HugeTLB pages of size 2MB and 1GB - * are currently supported. Since the base page size on x86 is 4KB, a 2MB - * HugeTLB page consists of 512 base pages and a 1GB HugeTLB page consists of - * 4096 base pages. For each base page, there is a corresponding page struct. - * - * Within the HugeTLB subsystem, only the first 4 page structs are used to - * contain unique information about a HugeTLB page. __NR_USED_SUBPAGE provides - * this upper limit. The only 'useful' information in the remaining page structs - * is the compound_head field, and this field is the same for all tail pages. - * - * By removing redundant page structs for HugeTLB pages, memory can be returned - * to the buddy allocator for other uses. - * - * Different architectures support different HugeTLB pages. For example, the - * following table is the HugeTLB page size supported by x86 and arm64 - * architectures. Because arm64 supports 4k, 16k, and 64k base pages and - * supports contiguous entries, so it supports many kinds of sizes of HugeTLB - * page. - * - * +--------------+-----------+-----------------------------------------------+ - * | Architecture | Page Size | HugeTLB Page Size | - * +--------------+-----------+-----------+-----------+-----------+-----------+ - * | x86-64 | 4KB | 2MB | 1GB | | | - * +--------------+-----------+-----------+-----------+-----------+-----------+ - * | | 4KB | 64KB | 2MB | 32MB | 1GB | - * | +-----------+-----------+-----------+-----------+-----------+ - * | arm64 | 16KB | 2MB | 32MB | 1GB | | - * | +-----------+-----------+-----------+-----------+-----------+ - * | | 64KB | 2MB | 512MB | 16GB | | - * +--------------+-----------+-----------+-----------+-----------+-----------+ - * - * When the system boot up, every HugeTLB page has more than one struct page - * structs which size is (unit: pages): - * - * struct_size = HugeTLB_Size / PAGE_SIZE * sizeof(struct page) / PAGE_SIZE - * - * Where HugeTLB_Size is the size of the HugeTLB page. We know that the size - * of the HugeTLB page is always n times PAGE_SIZE. So we can get the following - * relationship. - * - * HugeTLB_Size = n * PAGE_SIZE - * - * Then, - * - * struct_size = n * PAGE_SIZE / PAGE_SIZE * sizeof(struct page) / PAGE_SIZE - * = n * sizeof(struct page) / PAGE_SIZE - * - * We can use huge mapping at the pud/pmd level for the HugeTLB page. - * - * For the HugeTLB page of the pmd level mapping, then - * - * struct_size = n * sizeof(struct page) / PAGE_SIZE - * = PAGE_SIZE / sizeof(pte_t) * sizeof(struct page) / PAGE_SIZE - * = sizeof(struct page) / sizeof(pte_t) - * = 64 / 8 - * = 8 (pages) - * - * Where n is how many pte entries which one page can contains. So the value of - * n is (PAGE_SIZE / sizeof(pte_t)). - * - * This optimization only supports 64-bit system, so the value of sizeof(pte_t) - * is 8. And this optimization also applicable only when the size of struct page - * is a power of two. In most cases, the size of struct page is 64 bytes (e.g. - * x86-64 and arm64). So if we use pmd level mapping for a HugeTLB page, the - * size of struct page structs of it is 8 page frames which size depends on the - * size of the base page. - * - * For the HugeTLB page of the pud level mapping, then - * - * struct_size = PAGE_SIZE / sizeof(pmd_t) * struct_size(pmd) - * = PAGE_SIZE / 8 * 8 (pages) - * = PAGE_SIZE (pages) - * - * Where the struct_size(pmd) is the size of the struct page structs of a - * HugeTLB page of the pmd level mapping. - * - * E.g.: A 2MB HugeTLB page on x86_64 consists in 8 page frames while 1GB - * HugeTLB page consists in 4096. - * - * Next, we take the pmd level mapping of the HugeTLB page as an example to - * show the internal implementation of this optimization. There are 8 pages - * struct page structs associated with a HugeTLB page which is pmd mapped. - * - * Here is how things look before optimization. - * - * HugeTLB struct pages(8 pages) page frame(8 pages) - * +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+ - * | | | 0 | -------------> | 0 | - * | | +-----------+ +-----------+ - * | | | 1 | -------------> | 1 | - * | | +-----------+ +-----------+ - * | | | 2 | -------------> | 2 | - * | | +-----------+ +-----------+ - * | | | 3 | -------------> | 3 | - * | | +-----------+ +-----------+ - * | | | 4 | -------------> | 4 | - * | PMD | +-----------+ +-----------+ - * | level | | 5 | -------------> | 5 | - * | mapping | +-----------+ +-----------+ - * | | | 6 | -------------> | 6 | - * | | +-----------+ +-----------+ - * | | | 7 | -------------> | 7 | - * | | +-----------+ +-----------+ - * | | - * | | - * | | - * +-----------+ - * - * The value of page->compound_head is the same for all tail pages. The first - * page of page structs (page 0) associated with the HugeTLB page contains the 4 - * page structs necessary to describe the HugeTLB. The only use of the remaining - * pages of page structs (page 1 to page 7) is to point to page->compound_head. - * Therefore, we can remap pages 1 to 7 to page 0. Only 1 page of page structs - * will be used for each HugeTLB page. This will allow us to free the remaining - * 7 pages to the buddy allocator. - * - * Here is how things look after remapping. - * - * HugeTLB struct pages(8 pages) page frame(8 pages) - * +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+ - * | | | 0 | -------------> | 0 | - * | | +-----------+ +-----------+ - * | | | 1 | ---------------^ ^ ^ ^ ^ ^ ^ - * | | +-----------+ | | | | | | - * | | | 2 | -----------------+ | | | | | - * | | +-----------+ | | | | | - * | | | 3 | -------------------+ | | | | - * | | +-----------+ | | | | - * | | | 4 | ---------------------+ | | | - * | PMD | +-----------+ | | | - * | level | | 5 | -----------------------+ | | - * | mapping | +-----------+ | | - * | | | 6 | -------------------------+ | - * | | +-----------+ | - * | | | 7 | ---------------------------+ - * | | +-----------+ - * | | - * | | - * | | - * +-----------+ - * - * When a HugeTLB is freed to the buddy system, we should allocate 7 pages for - * vmemmap pages and restore the previous mapping relationship. - * - * For the HugeTLB page of the pud level mapping. It is similar to the former. - * We also can use this approach to free (PAGE_SIZE - 1) vmemmap pages. - * - * Apart from the HugeTLB page of the pmd/pud level mapping, some architectures - * (e.g. aarch64) provides a contiguous bit in the translation table entries - * that hints to the MMU to indicate that it is one of a contiguous set of - * entries that can be cached in a single TLB entry. - * - * The contiguous bit is used to increase the mapping size at the pmd and pte - * (last) level. So this type of HugeTLB page can be optimized only when its - * size of the struct page structs is greater than 1 page. - * - * Notice: The head vmemmap page is not freed to the buddy allocator and all - * tail vmemmap pages are mapped to the head vmemmap page frame. So we can see - * more than one struct page struct with PG_head (e.g. 8 per 2 MB HugeTLB page) - * associated with each HugeTLB page. The compound_head() can handle this - * correctly (more details refer to the comment above compound_head()). + * See Documentation/vm/vmemmap_dedup.rst */ #define pr_fmt(fmt) "HugeTLB: " fmt From patchwork Thu Mar 3 21:32:51 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joao Martins X-Patchwork-Id: 12768179 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8AA85C433F5 for ; Thu, 3 Mar 2022 21:33:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9D4CA8D0006; Thu, 3 Mar 2022 16:33:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 984368D0001; Thu, 3 Mar 2022 16:33:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 760388D0006; Thu, 3 Mar 2022 16:33:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 670768D0001 for ; Thu, 3 Mar 2022 16:33:48 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 1F4AE256F6 for ; Thu, 3 Mar 2022 21:33:48 +0000 (UTC) X-FDA: 79204377336.03.F36744C Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf15.hostedemail.com (Postfix) with ESMTP id 4CE7BA0007 for ; Thu, 3 Mar 2022 21:33:47 +0000 (UTC) Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 223KEiiT017342; Thu, 3 Mar 2022 21:33:42 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : content-type : mime-version; s=corp-2021-07-09; bh=R8DDQkIFxc/pBmzUTrpNK1/RSulJ0EPErufrYnIhA6o=; b=ZA3gx6DIsWk+JXBwuLLd9ikiz3dfNi+OJp/Nved9ogUtBlvnkBzI3jyRq5++hIFncJz3 saTxhojvETHXuF+xFfKiAufWumT9oxO3SxBjdxuilpG+mPk3+RLsV7Zu9vxS3OYO7GpD tUPboJOc0t/O02iXkYb+zeY/mCon6Y38MSgGgqxNZ5tZu/V6Ds+KEwdFXNylOMT7Ovui 2J3wkBm22fC9kWQg4XivRKB18XN5qX6o0mLht6J1F77SivtDMf53osEIE1ZZFSdhlGxH YUmuo5BhLoqGSTXCpZx5s3upBNXREAKPcW0neBUzdGjnQ+LExeVTAoHEaYjRWMZW4Pir ig== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by mx0b-00069f02.pphosted.com with ESMTP id 3ek4hvg5hm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 03 Mar 2022 21:33:41 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.1.2/8.16.1.2) with SMTP id 223LKueo132178; Thu, 3 Mar 2022 21:33:40 GMT Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2043.outbound.protection.outlook.com [104.47.66.43]) by aserp3020.oracle.com with ESMTP id 3ek4j7tq3n-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 03 Mar 2022 21:33:40 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mcbHsimnoGu4eHh8ggmJ1ubKRIh5AEX8pfNvtHgwOcoG5W3gCrXbNWy2EhQ9DIGMxZti4lhiOH2kv1xt0dwHICSgs6dwiGLhx8N3xH6GgW/J/OOWE7uDvdoYOGrQNf7Mt886Jy9CTdd2B80xtagPUu1Pmdr1bVLXVB04BhJ4n2CPi1vzBVIEca0cOmFntJC405rXjmclVuvr0Lu+c/vcrZ0qlhIZPuNylR2+z9cltRxtjdaSMfrrpqFeOBGzCkwc5Eiscaai4TBKa042PI3t14T30npnwVJHEIawxbLFX4Py89T3P1A0aiEF/zobX6OjCkz+tyok9H89E+7HtUVMfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=R8DDQkIFxc/pBmzUTrpNK1/RSulJ0EPErufrYnIhA6o=; b=Jad8Yp9bgWY/rcaIDPlgC5ot57nP+CxYigTd8RpmzMCUhGgFEuIv15NdzE+2op8jURp2odP+ve+vGwDgHr028WRq9GL51qcbQK8F0f/tBejgTtw5oAeIQLIWDSei4NmU74645b4SBl91vvMwFLnD0sdd+x29AFppBH6C5uKMey0lG6n63HUtlKd+v4MHn+JQh0ocwWtx/Ok+vY4Cc4HTbm7b+slkbzcN0xpKpVKqwD53liP2FtePhTZT1jjyC2bPCj8nfo36MxMhYhGAW8zKmJXAEKGtwYrkc2fWGFDTx3+HKvgCQxYupoKtbnhRigkAJK6HJ5TLbS6pfAmjRI12xw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R8DDQkIFxc/pBmzUTrpNK1/RSulJ0EPErufrYnIhA6o=; b=hU5qAAn1qylKorlMEMmRIZGVssQOjziOyACbu+OjIG2olfxnaRcbz64FzRap3x2uInrqdiP5Ge0CxG2bdT30kRQCULQjtUnAeUSl+knpsfOPfhk/QYmQMv466N1WEy31GTqpxj2I6v+wlvQg1NMj/lFPPb2H9N6wnz0wUUYrPbo= Received: from BLAPR10MB4835.namprd10.prod.outlook.com (2603:10b6:208:331::11) by DM5PR10MB1658.namprd10.prod.outlook.com (2603:10b6:4:4::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.15; Thu, 3 Mar 2022 21:33:36 +0000 Received: from BLAPR10MB4835.namprd10.prod.outlook.com ([fe80::750f:bf1d:1599:3406]) by BLAPR10MB4835.namprd10.prod.outlook.com ([fe80::750f:bf1d:1599:3406%5]) with mapi id 15.20.5038.014; Thu, 3 Mar 2022 21:33:36 +0000 From: Joao Martins To: linux-mm@kvack.org Cc: Dan Williams , Vishal Verma , Matthew Wilcox , Jason Gunthorpe , Jane Chu , Muchun Song , Mike Kravetz , Andrew Morton , Jonathan Corbet , Christoph Hellwig , nvdimm@lists.linux.dev, linux-doc@vger.kernel.org, Joao Martins Subject: [PATCH v7 4/5] mm/sparse-vmemmap: improve memory savings for compound devmaps Date: Thu, 3 Mar 2022 21:32:51 +0000 Message-Id: <20220303213252.28593-5-joao.m.martins@oracle.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20220303213252.28593-1-joao.m.martins@oracle.com> References: <20220303213252.28593-1-joao.m.martins@oracle.com> X-ClientProxiedBy: LO4P123CA0036.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:151::23) To BLAPR10MB4835.namprd10.prod.outlook.com (2603:10b6:208:331::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 035768f9-d9e4-4ef2-4d87-08d9fd5d797b X-MS-TrafficTypeDiagnostic: DM5PR10MB1658:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Yb5nHGCOKKfFpblcjwv1M+3O5ByXJrOmuObOXNgZD0hr0P0BvEMcZBPGHFVEl8cP8iGOM1GN7ylRprLtzSO8WIG3Gc7FVv573HC5gjldi2r8SUmmSig8auJznFCO7/R+2ks2MnowfLFp/3nQL9xrq68WdLTq4w5lqJzcsFpk0IcCJAWFyVQ67Clz310vZLmca5qN7Aca/rYhZ2tnDTUrstIQfOVIzeN5G2NKiXW9ITCy8+lKZrkmH9uFJjP8joResSDye0Kwi6P2frXx5dUOOMHRav5eCnKOtndAmG6NVk/Pumbu84WAj8sLIkViwN0c/3KCiTmkBxJjZb4EISzTvds+JMIve8vs5deqWPck6Z7k79rpWjB/u3BqvKHzkiF/gQeOiF4TAM918lR0JYzCySw0rC+Fj4usaxq2fOmZbR7EneMlzVjr9RauNgE/U2u3X1O/70f9XOxUYQHyurGsFfbBhQxbXm+Yjx8tkXx6heTakuIKnHEhyj0JTjgYP2fVhQNdcKSVQ4EwM7FOkiREgbnCxQuqFeL0K1I28xDEYvTSw4LI3KC85AP0VI9CvRiq7K5PdJXY+5CABolwPz1j75Ih8CJWJy/EgsRqyvt0dOpro5qyquuTuCPxCC1qsrtjQQND9WJwpzeuSoWN6miyCgXFvtJe73cgoQX2gw17jAXAUYXGpLeuyKl0aFtyAEf+1QYay0rUqMSr98vw2GBvv3DOwtqKFWH9aieu10vZQ7M= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BLAPR10MB4835.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230001)(366004)(83380400001)(38100700002)(38350700002)(186003)(107886003)(26005)(1076003)(5660300002)(36756003)(30864003)(103116003)(2906002)(7416002)(8936002)(66946007)(508600001)(66556008)(86362001)(6486002)(66476007)(6512007)(52116002)(316002)(2616005)(8676002)(4326008)(6916009)(6506007)(6666004)(54906003)(25903002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: EhuiSpDeBMSmJRDb5G8OJS999MZ8191mQ5k4B1KL2/D30cnXce/Kmk1P3thTRb+n0qDQ3CAnjjJElM17pJRIyM2f9ZKdDD1wJiPWgBXVR/MvycJvNTGhu4OBSyrlbT6dk8cbHk4guCroFxaPDPIwpYZ91PkbraS6usUZMSdOPgXgR2ccv9/F0zYRetWuetxM2FyD+KCr3xmD66Yn3YYAkzrOxj0BE7GxCdWazibERT4zJRUr10jpQTKptlSOMxwUjd74CkaDll4J9iE4H6bCa54RZvRqxqgDkudYu+da5gpWBvSm+RzIRJ3ksox1E/CPA5324R1lgpXm97uJxqe55GyX4Uq9sFUrVRpWul3neAHjDGCY1Q7rx0nuMbUzZJkf7/1xpR/Tro1pkXMvtoQmYb+0XoMxh8I1+PzdHruTHLuHoZ8T4cg1JeWplUzvtycSflwqOuMK2Ka7l3CgwynCZtobSaoCnsKdNK5Gj38ws8LyWjD3ytqpTw2izkfzad3+SvGHBATyF+mwOMCH/O3dbYzfUFRTZp58pJm5yOAJdI0VVsJvJsRgTEibCnKOyg9w2vqhWfb0DkG0WD/pBiCISjItR01bvnTR50EW/TitdS6P/bgaTAYbPOALK3TLF2RheSjpeV0BMAPDMc3eVf+iwtBxCa+Dqe8ar8wRz6NxSB1ig2cbyxAI0nbZs9aiiCPA+gSFvcPGHcERbR9k/FeeQAUg6TKTQnJf8Jg42/cRn5yMBkARJiAnB+22w8rZz8ZEHpsx1aIiIENI/k3KuNluJHoI9RDIgM+JMcJoSFpoqRog4yvc1C4U41ilKL5AwElwi8gSKd1j0pxn9BwA/Md/IzivGshROjYN/SNdCjxgQ6Jsamqixzd4n+RHKmVmEp88/NCD5tX2bWSDUyP9UMc8v6Kf8V8P1wa9Uewmzwc2+UJTEj6v0srApkGnIUh3RaMa4xyNlvmGeEXQ98JAzFViNEiZ2Z9U6D4NaFpX6vcYPFQgGqUDVZbBX7jNvl36PgKrL5tX2Kh3UFh5beHDjAqC1QhkvzaQiny9XLJOkBLEwdN95Md4r2HY6BFr68kEKAe3cwvhX4cftYw7jloqdbxR1RUETIuPtCaGfnqNBcRrSL9VutX5g+21WDXwb75DQ6fMrRaq4ZlIhVjviq6U1flk7usGiTD10XCSY0/44Ih/LfaP0YxU7qiMSXAjpXsDTSnE2vml3KDK/FFYaLvzx+k/6rzfEil5pGAP7vmfxYmhoJr4EmOKbThtOL5wry4tU/qJwPBXWPle/Tv8oLr++Lmj8F149N9313VUVYA10/q9/cpp/KAZXWHGvW0jv3U29IdS2INGJgwih+phgh+OD4spQ/N5z2NwttqQezFL9y9sGUnBkVj6ANadl2U6aEhfEm++i72Ae5l8ZPitcaXDfG8hmyz9BDD8pF2f6j7VyJpNJDHbVDq/nA0MCZ1JuGWc+gzW9iJf+5mdF1wDz4mUNmK1vcHTO8WAPGv/EKBEK+Ih52OX/3qYUDdsC8wBvS/E+0wQIEJQUapfau/pt9nu9nRLAGIcfrWFcBCVrtRAFbwbfbr70AasTCd9d+HejLWblu68Xt9u6DVy+2aCR2QUyVn4fWkEvFzkLCf/dFnK0OQV6b/ugxpO+nKy5iT8JwRP74QVsE60PuHWuNRFX7VrkYsSiA== X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 035768f9-d9e4-4ef2-4d87-08d9fd5d797b X-MS-Exchange-CrossTenant-AuthSource: BLAPR10MB4835.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2022 21:33:36.4670 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 0pqN52rIBlRq1tJwpjn+u4YoVcjZwvjVPOg2mdtuh7K4tGe9xXtD27ZFHG840Kf7g+gk2sE8nBn0llREqai5MhoUxD6VY10w341xWp92Ghg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR10MB1658 X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10275 signatures=686983 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 bulkscore=0 malwarescore=0 mlxscore=0 spamscore=0 suspectscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203030097 X-Proofpoint-ORIG-GUID: xQ0U74XWOP81Sb0ZUjj9f4bgMr_aGQdT X-Proofpoint-GUID: xQ0U74XWOP81Sb0ZUjj9f4bgMr_aGQdT X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 4CE7BA0007 X-Stat-Signature: r8ah7g9dq99amia7uonxd3wpetnscjw6 Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2021-07-09 header.b=ZA3gx6DI; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=hU5qAAn1; spf=none (imf15.hostedemail.com: domain of joao.m.martins@oracle.com has no SPF policy when checking 205.220.165.32) smtp.mailfrom=joao.m.martins@oracle.com; dmarc=pass (policy=none) header.from=oracle.com X-HE-Tag: 1646343227-227347 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: A compound devmap is a dev_pagemap with @vmemmap_shift > 0 and it means that pages are mapped at a given huge page alignment and utilize uses compound pages as opposed to order-0 pages. Take advantage of the fact that most tail pages look the same (except the first two) to minimize struct page overhead. Allocate a separate page for the vmemmap area which contains the head page and separate for the next 64 pages. The rest of the subsections then reuse this tail vmemmap page to initialize the rest of the tail pages. Sections are arch-dependent (e.g. on x86 it's 64M, 128M or 512M) and when initializing compound devmap with big enough @vmemmap_shift (e.g. 1G PUD) it may cross multiple sections. The vmemmap code needs to consult @pgmap so that multiple sections that all map the same tail data can refer back to the first copy of that data for a given gigantic page. On compound devmaps with 2M align, this mechanism lets 6 pages be saved out of the 8 necessary PFNs necessary to set the subsection's 512 struct pages being mapped. On a 1G compound devmap it saves 4094 pages. Altmap isn't supported yet, given various restrictions in altmap pfn allocator, thus fallback to the already in use vmemmap_populate(). It is worth noting that altmap for devmap mappings was there to relieve the pressure of inordinate amounts of memmap space to map terabytes of pmem. With compound pages the motivation for altmaps for pmem gets reduced. Signed-off-by: Joao Martins Reviewed-by: Muchun Song --- Documentation/vm/vmemmap_dedup.rst | 56 +++++++++++- include/linux/mm.h | 2 +- mm/memremap.c | 1 + mm/sparse-vmemmap.c | 132 ++++++++++++++++++++++++++--- 4 files changed, 177 insertions(+), 14 deletions(-) diff --git a/Documentation/vm/vmemmap_dedup.rst b/Documentation/vm/vmemmap_dedup.rst index 8143b2ce414d..de958bbbf78c 100644 --- a/Documentation/vm/vmemmap_dedup.rst +++ b/Documentation/vm/vmemmap_dedup.rst @@ -2,9 +2,12 @@ .. _vmemmap_dedup: -================================== -Free some vmemmap pages of HugeTLB -================================== +========================================= +A vmemmap diet for HugeTLB and Device DAX +========================================= + +HugeTLB +======= The struct page structures (page structs) are used to describe a physical page frame. By default, there is a one-to-one mapping from a page frame to @@ -173,3 +176,50 @@ tail vmemmap pages are mapped to the head vmemmap page frame. So we can see more than one struct page struct with PG_head (e.g. 8 per 2 MB HugeTLB page) associated with each HugeTLB page. The compound_head() can handle this correctly (more details refer to the comment above compound_head()). + +Device DAX +========== + +The device-dax interface uses the same tail deduplication technique explained +in the previous chapter, except when used with the vmemmap in +the device (altmap). + +The following page sizes are supported in DAX: PAGE_SIZE (4K on x86_64), +PMD_SIZE (2M on x86_64) and PUD_SIZE (1G on x86_64). + +The differences with HugeTLB are relatively minor. + +It only use 3 page structs for storing all information as opposed +to 4 on HugeTLB pages. + +There's no remapping of vmemmap given that device-dax memory is not part of +System RAM ranges initialized at boot. Thus the tail page deduplication +happens at a later stage when we populate the sections. HugeTLB reuses the +the head vmemmap page representing, whereas device-dax reuses the tail +vmemmap page. This results in only half of the savings compared to HugeTLB. + +Deduplicated tail pages are not mapped read-only. + +Here's how things look like on device-dax after the sections are populated: + + +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+ + | | | 0 | -------------> | 0 | + | | +-----------+ +-----------+ + | | | 1 | -------------> | 1 | + | | +-----------+ +-----------+ + | | | 2 | ----------------^ ^ ^ ^ ^ ^ + | | +-----------+ | | | | | + | | | 3 | ------------------+ | | | | + | | +-----------+ | | | | + | | | 4 | --------------------+ | | | + | PMD | +-----------+ | | | + | level | | 5 | ----------------------+ | | + | mapping | +-----------+ | | + | | | 6 | ------------------------+ | + | | +-----------+ | + | | | 7 | --------------------------+ + | | +-----------+ + | | + | | + | | + +-----------+ diff --git a/include/linux/mm.h b/include/linux/mm.h index 5f549cf6a4e8..ad7a845f15b8 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -3118,7 +3118,7 @@ p4d_t *vmemmap_p4d_populate(pgd_t *pgd, unsigned long addr, int node); pud_t *vmemmap_pud_populate(p4d_t *p4d, unsigned long addr, int node); pmd_t *vmemmap_pmd_populate(pud_t *pud, unsigned long addr, int node); pte_t *vmemmap_pte_populate(pmd_t *pmd, unsigned long addr, int node, - struct vmem_altmap *altmap); + struct vmem_altmap *altmap, struct page *reuse); void *vmemmap_alloc_block(unsigned long size, int node); struct vmem_altmap; void *vmemmap_alloc_block_buf(unsigned long size, int node, diff --git a/mm/memremap.c b/mm/memremap.c index 2e9148a3421a..a6be2f5bf443 100644 --- a/mm/memremap.c +++ b/mm/memremap.c @@ -307,6 +307,7 @@ void *memremap_pages(struct dev_pagemap *pgmap, int nid) { struct mhp_params params = { .altmap = pgmap_altmap(pgmap), + .pgmap = pgmap, .pgprot = PAGE_KERNEL, }; const int nr_range = pgmap->nr_range; diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c index 1b30a82f285e..642e4c8467b6 100644 --- a/mm/sparse-vmemmap.c +++ b/mm/sparse-vmemmap.c @@ -533,16 +533,31 @@ void __meminit vmemmap_verify(pte_t *pte, int node, } pte_t * __meminit vmemmap_pte_populate(pmd_t *pmd, unsigned long addr, int node, - struct vmem_altmap *altmap) + struct vmem_altmap *altmap, + struct page *reuse) { pte_t *pte = pte_offset_kernel(pmd, addr); if (pte_none(*pte)) { pte_t entry; void *p; - p = vmemmap_alloc_block_buf(PAGE_SIZE, node, altmap); - if (!p) - return NULL; + if (!reuse) { + p = vmemmap_alloc_block_buf(PAGE_SIZE, node, altmap); + if (!p) + return NULL; + } else { + /* + * When a PTE/PMD entry is freed from the init_mm + * there's a a free_pages() call to this page allocated + * above. Thus this get_page() is paired with the + * put_page_testzero() on the freeing path. + * This can only called by certain ZONE_DEVICE path, + * and through vmemmap_populate_compound_pages() when + * slab is available. + */ + get_page(reuse); + p = page_to_virt(reuse); + } entry = pfn_pte(__pa(p) >> PAGE_SHIFT, PAGE_KERNEL); set_pte_at(&init_mm, addr, pte, entry); } @@ -609,7 +624,8 @@ pgd_t * __meminit vmemmap_pgd_populate(unsigned long addr, int node) } static pte_t * __meminit vmemmap_populate_address(unsigned long addr, int node, - struct vmem_altmap *altmap) + struct vmem_altmap *altmap, + struct page *reuse) { pgd_t *pgd; p4d_t *p4d; @@ -629,7 +645,7 @@ static pte_t * __meminit vmemmap_populate_address(unsigned long addr, int node, pmd = vmemmap_pmd_populate(pud, addr, node); if (!pmd) return NULL; - pte = vmemmap_pte_populate(pmd, addr, node, altmap); + pte = vmemmap_pte_populate(pmd, addr, node, altmap, reuse); if (!pte) return NULL; vmemmap_verify(pte, node, addr, addr + PAGE_SIZE); @@ -639,13 +655,14 @@ static pte_t * __meminit vmemmap_populate_address(unsigned long addr, int node, static int __meminit vmemmap_populate_range(unsigned long start, unsigned long end, int node, - struct vmem_altmap *altmap) + struct vmem_altmap *altmap, + struct page *reuse) { unsigned long addr = start; pte_t *pte; for (; addr < end; addr += PAGE_SIZE) { - pte = vmemmap_populate_address(addr, node, altmap); + pte = vmemmap_populate_address(addr, node, altmap, reuse); if (!pte) return -ENOMEM; } @@ -656,7 +673,95 @@ static int __meminit vmemmap_populate_range(unsigned long start, int __meminit vmemmap_populate_basepages(unsigned long start, unsigned long end, int node, struct vmem_altmap *altmap) { - return vmemmap_populate_range(start, end, node, altmap); + return vmemmap_populate_range(start, end, node, altmap, NULL); +} + +/* + * For compound pages bigger than section size (e.g. x86 1G compound + * pages with 2M subsection size) fill the rest of sections as tail + * pages. + * + * Note that memremap_pages() resets @nr_range value and will increment + * it after each range successful onlining. Thus the value or @nr_range + * at section memmap populate corresponds to the in-progress range + * being onlined here. + */ +static bool __meminit reuse_compound_section(unsigned long start_pfn, + struct dev_pagemap *pgmap) +{ + unsigned long nr_pages = pgmap_vmemmap_nr(pgmap); + unsigned long offset = start_pfn - + PHYS_PFN(pgmap->ranges[pgmap->nr_range].start); + + return !IS_ALIGNED(offset, nr_pages) && nr_pages > PAGES_PER_SUBSECTION; +} + +static pte_t * __meminit compound_section_tail_page(unsigned long addr) +{ + pte_t *pte; + + addr -= PAGE_SIZE; + + /* + * Assuming sections are populated sequentially, the previous section's + * page data can be reused. + */ + pte = pte_offset_kernel(pmd_off_k(addr), addr); + if (!pte) + return NULL; + + return pte; +} + +static int __meminit vmemmap_populate_compound_pages(unsigned long start_pfn, + unsigned long start, + unsigned long end, int node, + struct dev_pagemap *pgmap) +{ + unsigned long size, addr; + pte_t *pte; + int rc; + + if (reuse_compound_section(start_pfn, pgmap)) { + pte = compound_section_tail_page(start); + if (!pte) + return -ENOMEM; + + /* + * Reuse the page that was populated in the prior iteration + * with just tail struct pages. + */ + return vmemmap_populate_range(start, end, node, NULL, + pte_page(*pte)); + } + + size = min(end - start, pgmap_vmemmap_nr(pgmap) * sizeof(struct page)); + for (addr = start; addr < end; addr += size) { + unsigned long next = addr, last = addr + size; + + /* Populate the head page vmemmap page */ + pte = vmemmap_populate_address(addr, node, NULL, NULL); + if (!pte) + return -ENOMEM; + + /* Populate the tail pages vmemmap page */ + next = addr + PAGE_SIZE; + pte = vmemmap_populate_address(next, node, NULL, NULL); + if (!pte) + return -ENOMEM; + + /* + * Reuse the previous page for the rest of tail pages + * See layout diagram in Documentation/vm/vmemmap_dedup.rst + */ + next += PAGE_SIZE; + rc = vmemmap_populate_range(next, last, node, NULL, + pte_page(*pte)); + if (rc) + return -ENOMEM; + } + + return 0; } struct page * __meminit __populate_section_memmap(unsigned long pfn, @@ -665,12 +770,19 @@ struct page * __meminit __populate_section_memmap(unsigned long pfn, { unsigned long start = (unsigned long) pfn_to_page(pfn); unsigned long end = start + nr_pages * sizeof(struct page); + int r; if (WARN_ON_ONCE(!IS_ALIGNED(pfn, PAGES_PER_SUBSECTION) || !IS_ALIGNED(nr_pages, PAGES_PER_SUBSECTION))) return NULL; - if (vmemmap_populate(start, end, nid, altmap)) + if (is_power_of_2(sizeof(struct page)) && + pgmap && pgmap_vmemmap_nr(pgmap) > 1 && !altmap) + r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); + else + r = vmemmap_populate(start, end, nid, altmap); + + if (r < 0) return NULL; return pfn_to_page(pfn); From patchwork Thu Mar 3 21:32:52 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joao Martins X-Patchwork-Id: 12768181 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A9A44C433EF for ; Thu, 3 Mar 2022 21:33:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6F2348D0001; Thu, 3 Mar 2022 16:33:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 593518D0009; Thu, 3 Mar 2022 16:33:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 16D9F8D0001; Thu, 3 Mar 2022 16:33:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0007.hostedemail.com [216.40.44.7]) by kanga.kvack.org (Postfix) with ESMTP id ECDEE8D0007 for ; Thu, 3 Mar 2022 16:33:48 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id A83ED182056D3 for ; Thu, 3 Mar 2022 21:33:48 +0000 (UTC) X-FDA: 79204377336.25.9751329 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf05.hostedemail.com (Postfix) with ESMTP id C580910000A for ; Thu, 3 Mar 2022 21:33:47 +0000 (UTC) Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 223KEiiU017342; Thu, 3 Mar 2022 21:33:44 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : content-type : mime-version; s=corp-2021-07-09; bh=4qmeluZwSkDehjJnpYTtA0DrESnXG3lMUA5AYBBy6FA=; b=LZ+pVjmW0wXiK5KPoVsIYRl/2XV4gJz/U329jTjKebZQ9SrVfkTMFsRbfmL00hNKqibE /9Dt6YGM++hA8DACb8FBBF/K5x57yZKPLQcF9ZUrWCIm/Nc5P46BXhA7L5xQdMDX5FIK bNylVO4V4AYQbvZHSuDjsx6bMEK7/jrTAQDumWM63p+9lQS5XlT/ZIIR9Up3SoLnc62B HZ625p3IYeTeAtpctlGLD0mV9Tc0A8kVF2Bl4nR0yb2U6Z2ny05Pqvpt2k/Vl+esEGhp ZqxzyrrYFQuErNP8PJ+JrqGd9LSkGXDcbPiNWhxXWfukSOQVXXXBo6pJGi6qnp7MSlbW xA== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by mx0b-00069f02.pphosted.com with ESMTP id 3ek4hvg5hq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 03 Mar 2022 21:33:44 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.1.2/8.16.1.2) with SMTP id 223LKuep132178; Thu, 3 Mar 2022 21:33:43 GMT Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2108.outbound.protection.outlook.com [104.47.55.108]) by aserp3020.oracle.com with ESMTP id 3ek4j7tq7b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 03 Mar 2022 21:33:42 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AnExle2XpmyZTbsJpUm3+LtlZq6cnDdq2MlW2nNT7l9WYJ+cLo1BvUYasFw5fHE5Vkm3yBAQYiu4HUop1JmBfTXbVPUzU6lsUG4z0Dji16fUwAdsB3eyPu1R0ES/vieiI6bl2zBOm1rhAJMxG6iB8oAWGhfF8ne930pecMPtKi9TbWHAmhOHUNG8AIFP0768FxS68haAd00+1roVQqZHylHTNKvF3IC9/t5pu4SU0OrTMTGU1GlcHkOZIOY+cEx30k+MgRZ2YiqiIpmMCA8knTt70uMs8Ft7kGeSQwRkeOuQG+/OdZ7A1fBlalvfBAcatT7DNIkP9z5TDzUr1PR4WQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4qmeluZwSkDehjJnpYTtA0DrESnXG3lMUA5AYBBy6FA=; b=mLuJOOAgKimNpVkgfxJmIU9Oo8tr/GJnMuhays/3+RO5VzlMn3zG4hJxO5aUdethW1iBtq8lXarI1QjbJEpfrBZHBddM9jXzLo/Q9IRlAt4GVjdHxDXrYkvSqT869sbI9wSgaSi22cU2Ymm8YOdkcWPa4h7uG/Rg7f8BhjPmhgeJyXk7pFe2YwQI6Li6UYO8eV71IIOlUWUi8EV9I8cU6lB/3nomAyJPIRJRk+ShDYT4D0SS0fzZM5XdLIl7RYcA94Q9elve1+7TbxGG6tjr+kL9hDmsLJtmiqNGzs3RHOf0H8CCR7os2jaKF+a1cgjF5lzJYrrR1hlyKCeV5bBqgQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4qmeluZwSkDehjJnpYTtA0DrESnXG3lMUA5AYBBy6FA=; b=Vv+z2UAT/wFLk7TWoSoWkW6KOJGGaJ/MHlsTzMGrXeAREgW8scPD82ecvjWeLJS9dyTYWqHtJ048NeE95nbYqzNoNdzZZG90XFjrr2YzsAiFzWJo7leZwf7KEcq5XCqX6XyIGyq/iUIuixghZCxfUGBZIjBEu7WCPAE/j9TtzMo= Received: from BLAPR10MB4835.namprd10.prod.outlook.com (2603:10b6:208:331::11) by MWHPR10MB1696.namprd10.prod.outlook.com (2603:10b6:301:8::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.14; Thu, 3 Mar 2022 21:33:40 +0000 Received: from BLAPR10MB4835.namprd10.prod.outlook.com ([fe80::750f:bf1d:1599:3406]) by BLAPR10MB4835.namprd10.prod.outlook.com ([fe80::750f:bf1d:1599:3406%5]) with mapi id 15.20.5038.014; Thu, 3 Mar 2022 21:33:39 +0000 From: Joao Martins To: linux-mm@kvack.org Cc: Dan Williams , Vishal Verma , Matthew Wilcox , Jason Gunthorpe , Jane Chu , Muchun Song , Mike Kravetz , Andrew Morton , Jonathan Corbet , Christoph Hellwig , nvdimm@lists.linux.dev, linux-doc@vger.kernel.org, Joao Martins Subject: [PATCH v7 5/5] mm/page_alloc: reuse tail struct pages for compound devmaps Date: Thu, 3 Mar 2022 21:32:52 +0000 Message-Id: <20220303213252.28593-6-joao.m.martins@oracle.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20220303213252.28593-1-joao.m.martins@oracle.com> References: <20220303213252.28593-1-joao.m.martins@oracle.com> X-ClientProxiedBy: LO4P123CA0036.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:151::23) To BLAPR10MB4835.namprd10.prod.outlook.com (2603:10b6:208:331::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 716135ad-5d3d-44ef-bbdc-08d9fd5d7b4e X-MS-TrafficTypeDiagnostic: MWHPR10MB1696:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: OuMvGk7XeCOaihqPuX/7e3fYDFHXQWJMUkBP+shmFq2te5QhdeymyhvJnFrf8EcHo/Vf7z2AJUabEo5OYxGn4J+LYyXkk7LJZQIZjMbSSXMehx7ELF4bnUDr+G4fYVnChw9+4SkXVzwodL0dVjyDBjsJudf62ATJTiVsEqcKE3ylU2vnv237kBzIWFMejUV7TXwt8c0ze1xyK9GeGNboQYY+oc3A/LouiRPNictZPOeiJa6V1hs7vJ06EuIiTDIZi+QAu3W3Up3LGzkpXZemJ5Vcpxv4ByIkNIBQlmgW7uJVdFwON8fD2FW0wAT37HHwpBs4kf+PviqbGnXHYkFiHNgqpSTF3TO+LKTcO2txUuuhP7WL205qYar663GWYDnIrj0UQTrEBXDa/RoZbvNvkDsHjIOnBewmpyeccdW7JjUwsrJVbR5pLQ2oR/jlYtfwEVNr9jj5pvpeoTxwgxDsfEXQXyTIr5uHOlSOrV1gKPXI/5hXtBI4Up66wJnuwCfsXCcCk1wfdcisnibgMDOjXHNlzCljdt88uXDiHHjH+GKH5n4A9aPMgnfp4GvTdEYEh0fVnm9M81+GdVaIP94HqXAfoRHNEw8oAxHzguPnvTHR8JSKWAJEVv9TPgQgnGtZf1gzxdPAugnBSmgwrEzHtK0pdJkG/ksynQxX9tAGfC3wnO6BD02kc/dtzqmfdUqp1FyTQEeBe/xi2O1/soQ3hQ== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BLAPR10MB4835.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230001)(366004)(5660300002)(2906002)(7416002)(1076003)(38350700002)(52116002)(107886003)(6506007)(54906003)(6916009)(6512007)(103116003)(26005)(8936002)(186003)(83380400001)(2616005)(36756003)(6666004)(316002)(508600001)(6486002)(4326008)(86362001)(8676002)(66476007)(66556008)(38100700002)(66946007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: BdfR1y4GRUtN5jFklHBsdHYdLY/0j++MffOB/OLRHXwF5QEg6uie2JqygF9ArzUGlU4r/2XZTy4wK4ylq1tbGspDqrpT7xNrZv6S6uj4stOgKEag2ueDZJoPJvUFCBZp1bTzjL2fuLtYR6U74gGOu5xHETEk/oMx3dtsm5iw8l9zXBnVgXl5Z1e+CTj+FqbN4ts6kHDD1W8Jf16+OhPCjtQsJ6ItKyGDL17tx18ZhjG6ECi/GJt3mWhgyVXZJPPuQEkps6a8s8AQhVy4C7C7eKHqeb4FJDh3IIbOz6dWojVI4cTo/BDj8H53ssasUlaOvguwh4SaTDpbKppHOqFUIfT/BviQaPbb3/RYXHepwR1mFzaNDGULz5Pm8pY8ZQtUKFnU7B78orHmoKb0Wj6Dn4UjIrZZxSRLqIB4p6gK33gN2BIkSd+BCojqlg9ElqUNQPVGgTBocSCTZgzzAbZzfEUZnwXXuw+OXMUxcu6juigcuNzvmXFOPbsVLs3YSxAozGCK4AMEzfr5xg/LIazYEf4+VLj2oRRKaVsarLPdvD5/bh+Q/gg6PLcEik50Hrg1UOhdYdFQPlOFsV3OKloa9iln7AtkkN4+BRaNleAyXfinfrWkYHPH+yp1WRWMbCj3XWkpLIbDDXOTJ4qtAHydLEHfDL/8ELxxzPIix8u9WVBEoguBArI2koDB5NsCAUxxSd8cA8kIkJmOU6C4jDKTjWv9HLiB0jeAbJxC+TsOtoza3Ya3o3yXtK2gBFVWtvD79gOKNBRo6eZV9HaV/1Hz+zjecXMAmjiJGnFAF/YUYUze2orufS7i2jqQ+V+OAp1KZ8vdMWDuTSMxoTt1POJSokjlF/UJ9dzxw1OLwN18+YEp3hO4qxAVJXZ9J1x+djlJnlgi+LY2QGenXGsSIoVkrb2Qnscw9kTQC2fNCakiuT3RjGs7hg5a9xEnkpdwezOQMTL+ZmGF6CAzU6rCu5kTV2SqicN5jVIHlIfKdy1omvwNb/hBRUHyzA4TYPQK7VGCOiTHFb0cX50lC5t24zreXaNsQxlYzMgRwrTzfFYLW+k43xZzL4zPLMR3u0y55egPZzDKqXm2TqJKT1HS6Tz/+SMGlyGmEAR1Wew7n9N5pMxjRY2eDpdf4MI7FjJfGJFk+D6P5WW9/jmKAypLZa5Lo/jgAPx/xLG1IHfxhV3Ju+utBujXXONZioT/xB/Cmcrzt0I0Ju3n+gjYjzZ3dYveuEpcZLPbMKUCGY6TVGXX1wExgvc+BXr9xRdbWES5Btm22/ni0wKs0k1aqSMnBMxrZJ3V4ZZZ0aqDh3NcOb03bdeew+aPnCpP/roSQ5YhgG/UhhZRQfXq6wHrTS8mWs6F10qER9N2Bgg12uf0OyTKbB0C4ep4D0arubLuuqCkjnmG0GYzH+mZWPS2MVGmVp1k2rXmTZECp62IGDrwS3ZOXpcTVbswkCRSn0xcS5tdJ9d3h73kvC3ntFEaamhFmEF3lTXtgocUsDuFu6XmnOpRGIlkRY3Cvy7Bfo7g/LT73/SNGI/BSk2dxq9GG6jXxwPvVmYI3+aj2EGy3my7zz+zhzd3R8zOeNfoERHXpiRbaBbxmuCguQYfTzCTI+AGK529tF5H7KLfzJUHbhKfc0m4eumqt+DZAWUq+9qb1bhQYpSNMZpgPD4EU9r7btrbYiQHfg== X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 716135ad-5d3d-44ef-bbdc-08d9fd5d7b4e X-MS-Exchange-CrossTenant-AuthSource: BLAPR10MB4835.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2022 21:33:39.5147 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: bAkBiI9LOomegX6KqRWxv1j/u+zpTtm0KST4d1nZ1ZcqdlSDq+L26DccoV2kY8h9P/S95eWj4IUhWgwKZDYtTup4gM4Hn1ByOeVKdxrXKGo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR10MB1696 X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10275 signatures=686983 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 bulkscore=0 malwarescore=0 mlxscore=0 spamscore=0 suspectscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203030097 X-Proofpoint-ORIG-GUID: flRcCNK2K6vIWmpLKDy5XHp-ymcwbWBH X-Proofpoint-GUID: flRcCNK2K6vIWmpLKDy5XHp-ymcwbWBH X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: C580910000A X-Stat-Signature: fbg9d91k7hwjyzd8dw314iptr8ctgt4u Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2021-07-09 header.b=LZ+pVjmW; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=Vv+z2UAT; spf=none (imf05.hostedemail.com: domain of joao.m.martins@oracle.com has no SPF policy when checking 205.220.165.32) smtp.mailfrom=joao.m.martins@oracle.com; dmarc=pass (policy=none) header.from=oracle.com X-Rspam-User: X-HE-Tag: 1646343227-971567 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Currently memmap_init_zone_device() ends up initializing 32768 pages when it only needs to initialize 128 given tail page reuse. That number is worse with 1GB compound pages, 262144 instead of 128. Update memmap_init_zone_device() to skip redundant initialization, detailed below. When a pgmap @vmemmap_shift is set, all pages are mapped at a given huge page alignment and use compound pages to describe them as opposed to a struct per 4K. With @vmemmap_shift > 0 and when struct pages are stored in ram (!altmap) most tail pages are reused. Consequently, the amount of unique struct pages is a lot smaller than the total amount of struct pages being mapped. The altmap path is left alone since it does not support memory savings based on compound pages devmap. Signed-off-by: Joao Martins Reviewed-by: Muchun Song --- mm/page_alloc.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index e0c1e6bb09dd..e9282d043cca 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -6653,6 +6653,21 @@ static void __ref __init_zone_device_page(struct page *page, unsigned long pfn, } } +/* + * With compound page geometry and when struct pages are stored in ram most + * tail pages are reused. Consequently, the amount of unique struct pages to + * initialize is a lot smaller that the total amount of struct pages being + * mapped. This is a paired / mild layering violation with explicit knowledge + * of how the sparse_vmemmap internals handle compound pages in the lack + * of an altmap. See vmemmap_populate_compound_pages(). + */ +static inline unsigned long compound_nr_pages(struct vmem_altmap *altmap, + unsigned long nr_pages) +{ + return is_power_of_2(sizeof(struct page)) && + !altmap ? 2 * (PAGE_SIZE/sizeof(struct page)) : nr_pages; +} + static void __ref memmap_init_compound(struct page *head, unsigned long head_pfn, unsigned long zone_idx, int nid, @@ -6717,7 +6732,7 @@ void __ref memmap_init_zone_device(struct zone *zone, continue; memmap_init_compound(page, pfn, zone_idx, nid, pgmap, - pfns_per_compound); + compound_nr_pages(altmap, pfns_per_compound)); } pr_info("%s initialised %lu pages in %ums\n", __func__,