From patchwork Thu Oct 19 02:31:02 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mike Kravetz X-Patchwork-Id: 13428188 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 B5D8FCDB482 for ; Thu, 19 Oct 2023 02:31:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4123F8007A; Wed, 18 Oct 2023 22:31:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3C23F80074; Wed, 18 Oct 2023 22:31:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 213DE8007A; Wed, 18 Oct 2023 22:31:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1127F80074 for ; Wed, 18 Oct 2023 22:31:56 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id DB0FEB642F for ; Thu, 19 Oct 2023 02:31:55 +0000 (UTC) X-FDA: 81360635790.03.F6860FD Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by imf24.hostedemail.com (Postfix) with ESMTP id 92B0B180007 for ; Thu, 19 Oct 2023 02:31:52 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-03-30 header.b=UtxYQkhU; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=iailQI9r; dmarc=pass (policy=none) header.from=oracle.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf24.hostedemail.com: domain of mike.kravetz@oracle.com designates 205.220.177.32 as permitted sender) smtp.mailfrom=mike.kravetz@oracle.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697682712; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=qOkbEny/iw4L9gnmc4DHbpV54PxWK9BmenSUQUQNoKo=; b=nhnutIexgzNMUevaSEToDpUttMk2/Qd5ReHHnBl1buoHoNrUfMgpQP9y//8byENI59YQh0 iJBfYQdLl2EauS2/IpbonDolXuKEJhQyW++8gpO8G2MSUg4lBrETNIt/TDP/GqHV+p7xC8 Dfbl/wN8lv/x5qceb7dNKJUUYCdUMfY= ARC-Authentication-Results: i=2; imf24.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-03-30 header.b=UtxYQkhU; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=iailQI9r; dmarc=pass (policy=none) header.from=oracle.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf24.hostedemail.com: domain of mike.kravetz@oracle.com designates 205.220.177.32 as permitted sender) smtp.mailfrom=mike.kravetz@oracle.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1697682712; a=rsa-sha256; cv=pass; b=A6G768ZOAO6BkCFG+0cisvfopqskgScVSRWhgHj0exS0AZfpZ7kLGZ8kvp6TFdNOSrErks 2dT0M2z52j7KchJiqi2xoHvhKpcWOaFLrWqNIhq+A2rKFlbZf5IZtW5NF6fXemEnOLiiyz 0TezhJTw3ySzSrLzn6a5A6N3Pvfzj2U= Received: from pps.filterd (m0246632.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 39IInBg9013656; Thu, 19 Oct 2023 02:31:21 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=corp-2023-03-30; bh=qOkbEny/iw4L9gnmc4DHbpV54PxWK9BmenSUQUQNoKo=; b=UtxYQkhURkKifd1pGDvOW1xVDemKXOd9kI5oRb7mt0QrFnqFDF2jeCNsQr6btBycpx7z Ik3MXHvwLT6zVBBn1Ek2k9oib2sp23ZWtVdCEAkifa/OyzbuC+Ml013OiveTiP7VSF20 ktc2juTRVX2uMJMKA/HMeT28LJWYRqlY9bIN6ahi2ZYMc8yzWI38VgxFt9fQWEX2GYFW I5dC7xtn6ncVyWTxPtGYlNTVULdpo7x5Zb+PNm0tjadQxWpbulYg2maLcNf6yoEwTejr kcWm6WkXcfqR2fgPfdeXHn+JL63Np9hvb9FJikYiiYvw0crpu1B8vQeOiR+PGNykxDt2 ZQ== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3tqk1d167t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Oct 2023 02:31:21 +0000 Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 39J1C4rs009668; Thu, 19 Oct 2023 02:31:20 GMT Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2041.outbound.protection.outlook.com [104.47.66.41]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3trg0q30bf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Oct 2023 02:31:20 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kkCaw5QQHHsBDZlwh5V2oWtdwK5SyJBXSSdHCQactbsJXEk4naosc4Xh9Ww7pC+aYb1wSQOuKVdo8pJ/UOTbm3p3GYP2yz9IVMME0YPPPHi3DbxcXhheSzc+CTgqI4MqT7sFGqPPjA3W623ngyAEaJzhYuzcH8iX7jOI9AxelE8ZPG9ZDyjK0KlzVE+qs8X8BQirkWH5NTFl8im0BwXIQiCWswqFQpnLYQV5FLBJriqqP/7ND/FjtY3kOAGGAongdI57y6rOhJaH2bya/q9hNKBzSY0sYGlYvnsHqIWZECCgsYKdIxqs5Poydt6RRmsfWPbpEl+ptOs4WydPm1XrZQ== 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=qOkbEny/iw4L9gnmc4DHbpV54PxWK9BmenSUQUQNoKo=; b=Dkbpydj9SYWGODaJMr2iId3qy8ak8LfVFkn6YG6VJSdECRrMGQWpj6WgB3hduEO8BpAMACW5Aubb1hV1VcsDZSR5ybULcC503DspFmjW6uvYkC8zHvZlXeDUFBUz+mmzCnZZ451lXo+Pmdm6GkMACDMCkoWU5biHqAnH4F/7otEr2f5CzuNOpsihPuUuH1kpsx+BHcElT/GrTysGzZ+Yg42wBSzY3lecQc7Xavo01tMCGdOJ6dewQkwh7je1cGtUAuK+Ls0pyjpLN3AIdrqXbbICt1wGTBJ4sqyST5ZOlv1ADTsYVFvYqOxCYRBi36/OyPvzpomkH9obJDFawPuJxQ== 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=qOkbEny/iw4L9gnmc4DHbpV54PxWK9BmenSUQUQNoKo=; b=iailQI9ru+kWH6iTrozO/kX201lDmmkF3bV+l3X3a1gqQfI7kcGXKgL5yA0Bd3MgqBupjTReXRuw9RVAwfXfEqE5x8X1bkDz529OsVil+5NWvNngFS4kXURxWSBDzCLxiYJlrEGkL963kHScMmWONmM5BLl75R2wGF0da39JUto= Received: from BY5PR10MB4196.namprd10.prod.outlook.com (2603:10b6:a03:20d::23) by CY8PR10MB7123.namprd10.prod.outlook.com (2603:10b6:930:74::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6886.36; Thu, 19 Oct 2023 02:31:17 +0000 Received: from BY5PR10MB4196.namprd10.prod.outlook.com ([fe80::59f7:ec45:eb41:d8c2]) by BY5PR10MB4196.namprd10.prod.outlook.com ([fe80::59f7:ec45:eb41:d8c2%6]) with mapi id 15.20.6863.032; Thu, 19 Oct 2023 02:31:17 +0000 From: Mike Kravetz To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Muchun Song , Joao Martins , Konrad Dybcio , Oscar Salvador , David Hildenbrand , Miaohe Lin , David Rientjes , Anshuman Khandual , Naoya Horiguchi , Barry Song <21cnbao@gmail.com>, Michal Hocko , Matthew Wilcox , Xiongchun Duan , Sergey Senozhatsky , Usama Arif , Andrew Morton , Mike Kravetz Subject: [PATCH v8 0/8] Batch hugetlb vmemmap modification operations Date: Wed, 18 Oct 2023 19:31:02 -0700 Message-ID: <20231019023113.345257-1-mike.kravetz@oracle.com> X-Mailer: git-send-email 2.41.0 X-ClientProxiedBy: MW4PR03CA0197.namprd03.prod.outlook.com (2603:10b6:303:b8::22) To BY5PR10MB4196.namprd10.prod.outlook.com (2603:10b6:a03:20d::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR10MB4196:EE_|CY8PR10MB7123:EE_ X-MS-Office365-Filtering-Correlation-Id: ce87bbd8-aee7-4633-2e88-08dbd04b7918 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: k6eFSPZCDC1ztunzJ6+BxGIRTO3vLJrio+XUMOMHxRZums1lfW/+LulgqaypUv7WwWPBYmnvmKiNsAmGIHOy9ODflo25/e8w46eEV5IAmhH6ysFsbMkZ3Wr9A5rkShAimQlhoMp5C8e9H4D5x4loeGUptiGNa4tXSJKCNokyu4mid8YxU1Y7jvjwkh5oRMfpkZxRLOciyeRjsXgh/4arsRSRUnDmrZRGHposbMFVoHEjfP+sXDTYkv3JGFuhInOxRRJpqofpgB+B6yY+xzBHS7R4JltOKqgPSl41ayq6+ror/YYi+2E5WABSa243/bIiu3rVgsiq5AgnegwClnXNhUgyBPHfGwmwmKD9kxIHrHDZrZWAZhiF4st42HAc3dS810H1ERnrCmiyB76CmjWLosZLkG5buvJ5Waiyzen3WQILnUtVLt1Tm1i4bGdgH1IRFg/ekkutfLf/Id8QYG8TbAcafc2k+dDfgqHldEWt1Xw/cJCNkh7hsqs/kB+VdKSsuruY8yyd72EYEbREQ9Mn1FiQmibyodNPVPOAelDrz3Dwtk6U7+2Lhw5tx/MOAbmi X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY5PR10MB4196.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(39860400002)(376002)(136003)(346002)(396003)(366004)(230922051799003)(1800799009)(186009)(64100799003)(451199024)(478600001)(54906003)(316002)(66946007)(66476007)(6486002)(66556008)(6666004)(1076003)(86362001)(2616005)(26005)(6506007)(36756003)(107886003)(6512007)(8936002)(2906002)(4326008)(8676002)(7416002)(44832011)(41300700001)(83380400001)(5660300002)(38100700002)(66899024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?q?nU6NkQjbmN/br/RZo6CCqzV1rKjb?= =?utf-8?q?Z7LLvdBYzOlhbt1ShvnchSG5O10Z9UKk72yiKkaBWEdY+Yg79O/aiaQ2bIspAwiYX?= =?utf-8?q?6pYTJjEfAuKrq4pvMfT9baSTAfaQVHVK8hM8uCA/2ReUWO8x4x5iOS2IPGBt+e7wO?= =?utf-8?q?nZPHXW9+4nznNGrznLxNZrWPgajvYK/Je1jm307QT4I8A/uFOf+jEvQ2Zk2GhgDjw?= =?utf-8?q?JsqRx9usIqoCYARo6qOjjD/UZ/gTTkHmJxHmmzP1P7kRmyqJ8Z6lPH6XF67mARxbo?= =?utf-8?q?GP0OoMTwvqliKXPtsgOWLa2yE9hpPjxY7u6GERNHcxpuzrjtUKhfEFZ0Bno+xm2E/?= =?utf-8?q?VbVja0JUhm/HpVo4uzkOOQoVYIq7E3H+FoHtJNMU40mNiuPxSpHZxFCJKK6XrNK4M?= =?utf-8?q?JEuAby6O+TQqExQPvwFTf/f76+dzIPlDSS5DoACq3zUbV1ZiILrxqwJTmcj+jVzEx?= =?utf-8?q?U41p5usZa5/IukTigHcWILbhyjLwoamd269v4crdWIsbID3xmXIkKJpYkmXEKtnZJ?= =?utf-8?q?7H32/T1a2OqRjAou5KrnZsrzE9k7PO6V4uHQNlt/na5cIoZQ9TMKhsthlnc3pYYH2?= =?utf-8?q?0vRvqNy8tJf2bDbDOfty9vb+QpBQB/Vf4SGj5JDSJRhi6/mAP4Yt7HOcKQe1/HQT7?= =?utf-8?q?Pz+8DITEM8Zex48/iWsnLoPBq6csPt1w+9QQdygWp5tTc3jZisIygw9fY1L0hybK2?= =?utf-8?q?G48cBi/KaZSv/vpdMBO6GraY7WpMkZQ8+PrnLCuetj7qUshApcZyXDy37xvqulidN?= =?utf-8?q?ym62GeTl68wvxEmI6n80tlFL6Zu7TFFZVxtvT1zEys2xiuCryZoWq/AfsEDt1zYqG?= =?utf-8?q?w6QEurFPZ3yOpDeQcPXSFM+4AQ0ABMrwtKwzpI39T5O9BpeHd4m93jxL5g1D7L4y3?= =?utf-8?q?x86p9NAPBDDpj//YJ/lWUSCBcrgzhoeszbZkWetY6ngJF+d/b6HqQYPsqwH4MYNC9?= =?utf-8?q?BDPVhKsNU0QRKy2yW6cwWcOb68RZYSHn3dP0StdqG6/KzNbbz7QeugMi0Y/z1+PQf?= =?utf-8?q?kBmEhaQPteaWEEMkAdeoCqng4gil0RMxDGQ6PlSd2RiMYg7/Tdbj6MBU1lGDy32+6?= =?utf-8?q?MRs+AwSje+86oKRmrFJluaQrstaHaeg8a/8sb4C5+aLRGgP1R7RwQGCTpddiDrHO0?= =?utf-8?q?pi2/WHDZ6ycpCnpQ26yTXBLt4nUjAZ+6PGuHUxkgKRAQ/VLZfRIQrtCuqWDXto51T?= =?utf-8?q?n6xZytD1Z9Jwz8MgEzx/mMWM/Gg46obIgZczzxkI1XHyxs3S+atLAEGxbDK2e/hXb?= =?utf-8?q?a7Uz+89WY8Hge8EbU8bpOte35ZJC6jcrHOkYtBvjzgEH2QgyMu6HHXfVhbjfovoA+?= =?utf-8?q?9if5lrfghuR0jGxzNTfJ8jdkZ05JyPhd4IAyP+NE+ggfMrifbW2psrd9/O0+Ke2wh?= =?utf-8?q?QIgtdzkOXHnhj/cnRtcK3w2P+RKuL+/+Lb2d75L+bugluA4i5HV6sJt86eFyvyf/7?= =?utf-8?q?zqyJNICBjoeQsbW3fWYmXYP6gIwwVGgKXoogEhuNCDYzjNf6aZkeQ9ag5YJYctq5V?= =?utf-8?q?0Vhym1ulpk2MwpG67fUGL9y58by33a8S1g=3D=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: =?utf-8?q?LAKMdGBnfryEH4yi?= =?utf-8?q?vtki5LXnzmyAl+fb2NhK0d5ecrgG5Asz2eEJNCNsUMRRxO/dozKMGVsOHXrVBujeK?= =?utf-8?q?FazuS0yGs1DiyfDsVgoC5Sul2ux6sEVxA/OLJjHlOKc14XBzwN8GnXEcIUZH8t2Lt?= =?utf-8?q?j9e+kfxJu8tXIJPza137k24qYl5R0Roaj+gl6vZAt5Dprnyf101f680ZckN7/HxNc?= =?utf-8?q?d2rf7vTgyA8ZtW5MIh2HTQm1faFHnwjWqNG9tICeCWs+r/ryXVbGDhQSntz8fqT+K?= =?utf-8?q?oz33CsU0B9mgZxyF/vs32CBOY2G2cFvIafxnxZjUDjUla/vKnFQEK5Z6HHqlbS6GG?= =?utf-8?q?QYGCrLak5yUW2FeT6NboMZjlZWo5UqUo3onq34xvHJeCpIeIUVrefChzaup8PNtFj?= =?utf-8?q?JjjhuT5hI+jUSh5p0QgwLmutBE4fekL0PviUgK61l84VLzUR+bs+f1zbg0Xl5QATE?= =?utf-8?q?UQzkuc+EegPn+hxbm4J7TP+R/gNhxSyOvQsrKN45d8JgQyrAoFcXNPeRZt6FuPFhZ?= =?utf-8?q?z/rRr3/8RVdcp6greDKm2bJNDR4agQQh8KHC4rpnBO2Hy6TyjXipsQJWvUFpoPMUz?= =?utf-8?q?WMhg7hhXqzPqUzNlDQBk7zrpf4RpAJfrWZR3MpSnxhmtZjt1XqbnKZLa02gIFoyzO?= =?utf-8?q?fQZirofGCaGj3y4O5r/8PGCEb3qXGOLWiNfNN0DJcbRCmJ3Le+Rg4OG807IEoLvJF?= =?utf-8?q?SHG1DQCa4m04gL/qfW031k0MSugPuQ1iVXbafu2TPqQdVNmUSJ04noQuxmMOAVv8j?= =?utf-8?q?/Vs0FlZEaCC9wVjyBcuR5JfK6pzNkH4bSLK/EZfuC5C5gvrG5nOqDteM0tRh9ax0G?= =?utf-8?q?PjBXVJJvUB9q+4TR75gtLkcZGtaNDes5PMM7foLtldrZKKXt9or0VMNsdz/KnL1Uj?= =?utf-8?q?f8axXzaDAEWPrEMNCNVoKtGH5yO3/G063YuZ1RgVCUxIhS8xjb1aGuVmRJop5n+OA?= =?utf-8?q?eyUxMDdUnDgol6TRxa1P2afBcRehHNAevo8Y+1/THNcPyuoU9Z9B8FLyloMqA9/r6?= =?utf-8?q?rr6ErgL/BHrd7W51cfgBW2I+ypHvQypnc+VTlkel88ClspIf3pmrvng8vWRFhE1Uy?= =?utf-8?q?qxGSYWLaazFUWX1RfE2G1fdL4J27wLMkDApiwq3UJG9jf35gSsGnj1NHdL+w5Yq76?= =?utf-8?q?Cx0oTcSJbnS1fwG8e6tWk1bZ694xqz?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce87bbd8-aee7-4633-2e88-08dbd04b7918 X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2023 02:31:17.7024 (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: xbd5kuvZ+I33nztJSeWC9P61lMrQFWQA+cemkqGbhTHu3fiLvmjgs1UilJLfvdMUvv6QSFVLIsQ7XX2ttWdffg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR10MB7123 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-10-19_02,2023-10-18_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 malwarescore=0 adultscore=0 suspectscore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2309180000 definitions=main-2310190019 X-Proofpoint-GUID: yK-Cknw7Toika0T0jfalQ7EAGDPtn4MU X-Proofpoint-ORIG-GUID: yK-Cknw7Toika0T0jfalQ7EAGDPtn4MU X-Rspamd-Queue-Id: 92B0B180007 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: tkagbnhwrd1miqkmm4d87cqthcxzn9nr X-HE-Tag: 1697682712-275645 X-HE-Meta: U2FsdGVkX1+kxNrn83iXKEKz6ice9wfuTc3rSEB/SbPZsBiTV9Lsxdimuaqpt7P7Hownu2YdJuEWrsjhYHIpHO2CAhB7qdicAgwrklEuM0u6yinf5gxPed1tD3Bm1h6FqzDxeMBkkxHahBibwdvP+MsSSizFgTxImq0u2pWfL6+rqRwBecEsGcMoE1Sglbeth7kjDrTM5vFhv9T56U/rkcteE1OpzL88+e+YmSkZiziBaf2r+VA65TOrzQj8X0umW3uKJiXcZNkq0Wi/w6GNPctyoazMThIXHtHHX0/XwVABeG6WQ3pTnJola8OamPLlf4NQUEABzbv8EyY1wEW4w2WPBxJYRFp28DTqRjUYXCJV1xSEdN4bJ6LYifrYdDBp/pAdIAXCJO7hMDzVnBYMDhdI+6EOOwmRC42cRdsyr2SIbiZA1G6dYXHxy2OI22vmTu9leqhfFHv1GbIua2EJ7k+1tZGxamHTFlwIq7QeM3QZyu6pi/8c/3T8ORLYm7QZsPygdveU+yK48Efmt2riOX8wz+cK8q1mo4ITysfmLkFQSla0z/iaHlVmp4yaMorrzgK1jMLBU5kvsHuU9cYFRd4e54FdFbUiqVLW0ifSlxBuoaB8gR2+4x/YvcbN/vtJLHfABjgtcZvxDpxNTAwsbdAyAumjATlCklvFe9hsSMKDIsqt44bwdsyHG0O7ciAZ+4ABTqPpsgak5J6YEEFNevLt/Nmkgi44Y3zWdHEuj7pmUivAtY/3R71a0r9je6lRf2gZPzsJBo7ikLlNGRDhGsYUUsmlvJaQCE67DV4DBQkOnFLYn/0/r9UUxqoPI9ovg3P0qb8SWBafCWF/bQYLHVtJ2yc6WGu9jtIdoQ4RDBa1lWaWydLFCXyYNWGCxaS/6clojmxCgRQXlGHAQqxZ9l1jbQhsz+2MZG00wyDEjuNZHmtipYvS9x5k6jx0HajRYniItLh7VyWQ2HYaYcl T8HXuFBH Siv3HOVrYn3iNt0VDxuEDVevKIAsc6/YxWbZE6kZycabrtB+JJIaYCdyc2dNz5KAOb3d/WvCjGNZICdJzJIjCkpXfuaTVXfGbQ+JKhvb/AN38esenVpOaBBq+twYaSVbvAMfhmL2tTZOhjkW6OzwdtHQtgUjl5Evb/wWyJSyuzSSRKWqu/wMmqc7/PBmVyoXhYszUF6Czmz34O05vzslttZxARTpG9bPJkWCkdZ5+Vnv8W21Srv9g44CozHgj1UTx9YuPqOsEw8DvsTXV24IbIGlSTFK6BODxW6bxrmSGxiMv8CtRyP8QnxWWW94ZCU/NZ+aSiv677uDNuXd5HnAUKr6LxbkGfA4/8jYgaJLMzURyPq2fJ/OV9Mfk/uJgUxdm4cpk8cYi7FjkkoIHu6NDCvwMBQ== 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: When hugetlb vmemmap optimization was introduced, the overhead of enabling the option was measured as described in commit 426e5c429d16 [1]. The summary states that allocating a hugetlb page should be ~2x slower with optimization and freeing a hugetlb page should be ~2-3x slower. Such overhead was deemed an acceptable trade off for the memory savings obtained by freeing vmemmap pages. It was recently reported that the overhead associated with enabling vmemmap optimization could be as high as 190x for hugetlb page allocations. Yes, 190x! Some actual numbers from other environments are: Bare Metal 8 socket Intel(R) Xeon(R) CPU E7-8895 ------------------------------------------------ Unmodified next-20230824, vm.hugetlb_optimize_vmemmap = 0 time echo 500000 > .../hugepages-2048kB/nr_hugepages real 0m4.119s time echo 0 > .../hugepages-2048kB/nr_hugepages real 0m4.477s Unmodified next-20230824, vm.hugetlb_optimize_vmemmap = 1 time echo 500000 > .../hugepages-2048kB/nr_hugepages real 0m28.973s time echo 0 > .../hugepages-2048kB/nr_hugepages real 0m36.748s VM with 252 vcpus on host with 2 socket AMD EPYC 7J13 Milan ----------------------------------------------------------- Unmodified next-20230824, vm.hugetlb_optimize_vmemmap = 0 time echo 524288 > .../hugepages-2048kB/nr_hugepages real 0m2.463s time echo 0 > .../hugepages-2048kB/nr_hugepages real 0m2.931s Unmodified next-20230824, vm.hugetlb_optimize_vmemmap = 1 time echo 524288 > .../hugepages-2048kB/nr_hugepages real 2m27.609s time echo 0 > .../hugepages-2048kB/nr_hugepages real 2m29.924s In the VM environment, the slowdown of enabling hugetlb vmemmap optimization resulted in allocation times being 61x slower. A quick profile showed that the vast majority of this overhead was due to TLB flushing. Each time we modify the kernel pagetable we need to flush the TLB. For each hugetlb that is optimized, there could be potentially two TLB flushes performed. One for the vmemmap pages associated with the hugetlb page, and potentially another one if the vmemmap pages are mapped at the PMD level and must be split. The TLB flushes required for the kernel pagetable, result in a broadcast IPI with each CPU having to flush a range of pages, or do a global flush if a threshold is exceeded. So, the flush time increases with the number of CPUs. In addition, in virtual environments the broadcast IPI can’t be accelerated by hypervisor hardware and leads to traps that need to wakeup/IPI all vCPUs which is very expensive. Because of this the slowdown in virtual environments is even worse than bare metal as the number of vCPUS/CPUs is increased. The following series attempts to reduce amount of time spent in TLB flushing. The idea is to batch the vmemmap modification operations for multiple hugetlb pages. Instead of doing one or two TLB flushes for each page, we do two TLB flushes for each batch of pages. One flush after splitting pages mapped at the PMD level, and another after remapping vmemmap associated with all hugetlb pages. Results of such batching are as follows: Bare Metal 8 socket Intel(R) Xeon(R) CPU E7-8895 ------------------------------------------------ next-20230824 + Batching patches, vm.hugetlb_optimize_vmemmap = 0 time echo 500000 > .../hugepages-2048kB/nr_hugepages real 0m4.719s time echo 0 > .../hugepages-2048kB/nr_hugepages real 0m4.245s next-20230824 + Batching patches, vm.hugetlb_optimize_vmemmap = 1 time echo 500000 > .../hugepages-2048kB/nr_hugepages real 0m7.267s time echo 0 > .../hugepages-2048kB/nr_hugepages real 0m13.199s VM with 252 vcpus on host with 2 socket AMD EPYC 7J13 Milan ----------------------------------------------------------- next-20230824 + Batching patches, vm.hugetlb_optimize_vmemmap = 0 time echo 524288 > .../hugepages-2048kB/nr_hugepages real 0m2.715s time echo 0 > .../hugepages-2048kB/nr_hugepages real 0m3.186s next-20230824 + Batching patches, vm.hugetlb_optimize_vmemmap = 1 time echo 524288 > .../hugepages-2048kB/nr_hugepages real 0m4.799s time echo 0 > .../hugepages-2048kB/nr_hugepages real 0m5.273s With batching, results are back in the 2-3x slowdown range. This series is based on mm-stable (October 18) Changed v7 -> v8: - patch 2 initialized h in gather_bootmem_prealloc so clang would not cause loop to be executed when entry condition false. - patch 2 changed locking in prep_and_add_allocated_folios to take into account that IRQs may be disabled. - patch 3 same locking changes for patch 2 above for prep_and_add_bootmem_folios - Removed Muchun RBs from patches although they are much the same Changes v6 -> v7: - Fixed hugetlb_vmemmap_restore_folios stub for the !CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP case - Added Muchun RB for patches 4 and 8 Changes v5 -> v6: - patch 4 in bulk_vmemmap_restore_error remove folio from list before calling add_hugetlb_folio. - Added Muchun RB for patches 2 and 3 Changes v4 -> v5: - patch 3 comment style updated, unnecessary INIT_LIST_HEAD - patch 4 updated hugetlb_vmemmap_restore_folios to pass back number of restored folios in non-error case. In addition, routine passes back list of folios with vmemmmap. Naming more consistent. - patch 5 remover over optimization and added Muchun RB - patch 6 break and early return in ENOMEM case. Updated comments. Added Muchun RB. - patch 7 Updated comments about splitting failure. Added Muchun RB. - patch 8 Made comments consistent. Changes v3 -> v4: - Rebased on mm-unstable and dropped requisite patches. - patch 2 updated to take bootmem vmemmap initialization into account - patch 3 more changes for bootmem hugetlb pages. added routine prep_and_add_bootmem_folios. - patch 5 in hugetlb_vmemmap_optimize_folios on ENOMEM check for list_empty before freeing and retry. This is more important in subsequent patch where we flush_tlb_all after ENOMEM. Changes v2 -> v3: - patch 5 was part of an earlier series that was not picked up. It is included here as it helps with batching optimizations. - patch 6 hugetlb_vmemmap_restore_folios is changed from type void to returning an error code as well as an additional output parameter providing the number folios for which vmemmap was actually restored. The caller can then be more intelligent about processing the list. - patch 9 eliminate local list in vmemmap_restore_pte. The routine hugetlb_vmemmap_optimize_folios checks for ENOMEM and frees accumulated vmemmap pages while processing the list. - patch 10 introduce flags field to struct vmemmap_remap_walk and VMEMMAP_SPLIT_NO_TLB_FLUSH for not flushing during pass to split PMDs. - patch 11 rename flag VMEMMAP_REMAP_NO_TLB_FLUSH and pass in from callers. Changes v1 -> v2: - patch 5 now takes into account the requirement that only compound pages with hugetlb flag set can be passed to vmemmmap routines. This involved separating the 'prep' of hugetlb pages even further. The code dealing with bootmem allocations was also modified so that batching is possible. Adding a 'batch' of hugetlb pages to their respective free lists is now done in one lock cycle. - patch 7 added description of routine hugetlb_vmemmap_restore_folios (Muchun). - patch 8 rename bulk_pages to vmemmap_pages and let caller be responsible for freeing (Muchun) - patch 9 use 'walk->remap_pte' to determine if a split only operation is being performed (Muchun). Removed unused variable and hugetlb_optimize_vmemmap_key (Muchun). - Patch 10 pass 'flags variable' instead of bool to indicate behavior and allow for future expansion (Muchun). Single flag VMEMMAP_NO_TLB_FLUSH. Provide detailed comment about the need to keep old and new vmemmap pages in sync (Muchun). - Patch 11 pass flag variable as in patch 10 (Muchun). Joao Martins (2): hugetlb: batch PMD split for bulk vmemmap dedup hugetlb: batch TLB flushes when freeing vmemmap Mike Kravetz (6): hugetlb: optimize update_and_free_pages_bulk to avoid lock cycles hugetlb: restructure pool allocations hugetlb: perform vmemmap optimization on a list of pages hugetlb: perform vmemmap restoration on a list of pages hugetlb: batch freeing of vmemmap pages hugetlb: batch TLB flushes when restoring vmemmap mm/hugetlb.c | 303 ++++++++++++++++++++++++++++++++++++------- mm/hugetlb_vmemmap.c | 273 ++++++++++++++++++++++++++++++++------ mm/hugetlb_vmemmap.h | 16 +++ 3 files changed, 509 insertions(+), 83 deletions(-)