From mboxrd@z Thu Jan 1 00:00:00 1970 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 D0ECCC7EE23 for ; Wed, 7 Jun 2023 22:07:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3BB816B0072; Wed, 7 Jun 2023 18:07:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 36BE56B0074; Wed, 7 Jun 2023 18:07:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 197408E0001; Wed, 7 Jun 2023 18:07:33 -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 084BC6B0072 for ; Wed, 7 Jun 2023 18:07:33 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id BFBAD1C782B for ; Wed, 7 Jun 2023 22:07:32 +0000 (UTC) X-FDA: 80877339144.12.482273C Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf28.hostedemail.com (Postfix) with ESMTP id 52191C0008 for ; Wed, 7 Jun 2023 22:07:29 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-03-30 header.b=ilwr3gJR; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=qvCle6wm; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf28.hostedemail.com: domain of mike.kravetz@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=mike.kravetz@oracle.com; dmarc=pass (policy=none) header.from=oracle.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686175649; 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:in-reply-to:references:references:dkim-signature; bh=TBPKPASYbOfEusA6tn5zp86bciV4uPQvVCdho1pKSEk=; b=P83bBhIbEz7jSdrZb411Xvaf+ltAz6DT73lnhasAykRD1uNhj10NarVv9BOT3cezzzRfsS I2XzFkfwHSpWRmntOSsL2Ni9PEDIay2VACUJYF5yVdtk4nhWNRv9UlDj15JXYrv0gpMuzO Ayk982knnXwGaOVMXcm+6Twj3m++bpw= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1686175649; a=rsa-sha256; cv=pass; b=a+iNr+qTlL+GiKBzslbifwUrKjjuc1g6fktqR7LXvWgCcozlcuvpTsB5epV4hBUMNUHDYO wEz+uFI/YsPgY4zfyVp6xb3x8cYsgQi/yoOG3gl8ihtv0kMfTleg1YS2lRMaRaByj4u/N9 mrC24ESVBfRyfKDDsQmw5KipSmcx3IU= ARC-Authentication-Results: i=2; imf28.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-03-30 header.b=ilwr3gJR; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=qvCle6wm; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf28.hostedemail.com: domain of mike.kravetz@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=mike.kravetz@oracle.com; dmarc=pass (policy=none) header.from=oracle.com Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 357EdNJ0011477; Wed, 7 Jun 2023 22:06:58 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : content-type : content-transfer-encoding : in-reply-to : mime-version; s=corp-2023-03-30; bh=TBPKPASYbOfEusA6tn5zp86bciV4uPQvVCdho1pKSEk=; b=ilwr3gJRPgp47kSuY658Fi7HLJ9bDQUwlHUtIq81jJ1ja3xJgFs64icpZEQgNt8bNwFA 4PrBDsJeEkxm0AbJD5lY19j1FDDB63O0eVpE6CQ71QgT398uAFLqXiuGhfaR87oZ7jPP brsoRBdL5K1xbelkDMSaI9ROd1E7MPUSa8BSKPTlhd+EJkAH/3OEBEZ7PuykR+8tCqsZ 9KdaP/fOtAoLw45SdgES3sSiceW7JEbh3vTeAHQTTotklMFZZzbl3VE+4Ah3gbntHwW0 YZJbOI/DLgzyIkLLlptSVBs9PCx0cgseciHoK6515EV0FfEvZh8E/e6Pm5dc1VTiSc53 9A== Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3r2a6utwfg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 07 Jun 2023 22:06:58 +0000 Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 357KdbY4036110; Wed, 7 Jun 2023 22:06:57 GMT Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2168.outbound.protection.outlook.com [104.47.58.168]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3r2a6s3n2d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 07 Jun 2023 22:06:56 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m/IBzt/DDLM8DYqFBqRw5rPHeAD1H/g8Ut7cZyfMG7Dw+Sagfop+W26GPpgugp+mxDOEjssZ+6EX2IIPoY105ZWTIGR3+uf96OfpmkGei0+/MwiY5Q0zppahj2oNt6DhYt1rsZioeP4nPJSr15Y4rYKtbxbtD3Y7pJZ2pwjB+lES3vM2uovJQs4nnJq2Pavoc4gmW132v0O69T2EmHZH2X2LceSybqfRUsk0qxj6EI3NVAWR90pbAlBTKheDEs++fC3cZouWRq7qveQF1FoT5wNVKhFAaHyRIkYlxb4MREcNZgscMKwM2pupj7a6T5uhoqrPzdWvfgzCfkSAekBoPg== 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=TBPKPASYbOfEusA6tn5zp86bciV4uPQvVCdho1pKSEk=; b=gBXlgOxeGxXLyVesimRRxXGgL5wsyhrw7eyCHoWE2DSe8c8QGOqM9E+05sWTh+BaiN+O/BXjDG4I6CAdy2KSULcd0u/fOo+vEnX4Zc/W1lnglpXb11QPNzYjOQLSunwJMXpQ1sMHWVO8ID52BpA8rcUKYBrQF2eTXdpxZpgLa89ou69kBq/VuxE+2kIu9CM2kztHsQPzRKRzAyFutdmZJIi4x3LLuHq5eGKaNLblEDb5+H2FYcOpK34lFZSYMAvL9MYII++elYtCYscCKYqKSQKToGOMcrEQtftuD8FY3dGgowcGzbG7kBMGGrOJixTsgsnD/p+a0dFIbBLYBNVarg== 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=TBPKPASYbOfEusA6tn5zp86bciV4uPQvVCdho1pKSEk=; b=qvCle6wmGwBSo3tA9iDvWa1DXgHhVCrTyGOuq2VC6bKf29yM3c8LPrtmQlSA/3p4qYwLdXzKx+Y/fYnhGuMMMW+2k7jr5yh/no7DF+MS3oTdnMzVZjtyVwwHvcYmgWnT3B5IQ6QLW2r2YUlF+xh0BTWgdjyO1crLu/ttR1GBg/4= Received: from BY5PR10MB4196.namprd10.prod.outlook.com (2603:10b6:a03:20d::23) by BN0PR10MB4839.namprd10.prod.outlook.com (2603:10b6:408:126::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6455.33; Wed, 7 Jun 2023 22:06:54 +0000 Received: from BY5PR10MB4196.namprd10.prod.outlook.com ([fe80::4a17:13b0:2876:97f2]) by BY5PR10MB4196.namprd10.prod.outlook.com ([fe80::4a17:13b0:2876:97f2%6]) with mapi id 15.20.6455.030; Wed, 7 Jun 2023 22:06:54 +0000 Date: Wed, 7 Jun 2023 15:06:51 -0700 From: Mike Kravetz To: David Hildenbrand Cc: Yosry Ahmed , David Rientjes , James Houghton , Naoya Horiguchi , Miaohe Lin , lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, Peter Xu , Michal Hocko , Matthew Wilcox , Axel Rasmussen , Jiaqi Yan Subject: Re: [LSF/MM/BPF TOPIC] HGM for hugetlbfs Message-ID: <20230607220651.GC4122@monkey> References: <20230306191944.GA15773@monkey> <20230602172723.GA3941@monkey> <7e0ce268-f374-8e83-2b32-7c53f025fec5@google.com> <7c42a738-d082-3338-dfb5-fd28f75edc58@redhat.com> <75d5662a-a901-1e02-4706-66545ad53c5c@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <75d5662a-a901-1e02-4706-66545ad53c5c@redhat.com> X-ClientProxiedBy: MW4PR03CA0334.namprd03.prod.outlook.com (2603:10b6:303:dc::9) To BY5PR10MB4196.namprd10.prod.outlook.com (2603:10b6:a03:20d::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR10MB4196:EE_|BN0PR10MB4839:EE_ X-MS-Office365-Filtering-Correlation-Id: 26493d91-4db9-4121-89b1-08db67a380ce X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 5KXL5Vrc70+hVPPBomSMdK2Wu5RPv95IE6SmCFfkXEARLoY48xidfdZqyXuF+GEtXite+5vbjBqwvPSSflP3e34egAOvxbir+7qku28GvasYIYWJHnDz5p99a2KrAYovY4aouS1uER5BHLYaHTQxw78bUc/Dl5qkDJJ0K3fHYx8lCcMixaeHL7AKvK8Mz5xPEhIVFaQ8XvW1S2seF6M++8Ve1M0kp3YxYcLkQ8ODMT3+6uqKoeRPOaVbhJKStdRv1VsG/Q6i9sb9Gc7K9Li6s9Jh7dcWiPFrheSzEdlYdcJ/Bpdqj7hJYQfdwM/ZxLeXvH5nWWG98ozHrFM0zrClQHh0ufBrN3M+ivYIliA2OA5U92mmEUbgP4/UbXG21fWKHrXx7SI62tS72Cct812PAtYIHHoSr3gjvvPYs9PteQZi3oF6nr/KUJIRD7Z4Rv2bVD+/VB+CmW6Y7CXBwQuzkf3QXX38H7YnOHXWQ650t0yExQiKKkRxOaVlUWTrHH5dUJ9X+CIuixpt57DNHTtFmy/juNXxzqpiC9tatFhDYFqznGeldBGqal3Nyb3TpQbu 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:(13230028)(7916004)(366004)(346002)(39860400002)(376002)(136003)(396003)(451199021)(54906003)(316002)(478600001)(6916009)(8936002)(8676002)(41300700001)(66946007)(4326008)(38100700002)(66556008)(66476007)(186003)(6486002)(6666004)(83380400001)(1076003)(6512007)(6506007)(26005)(53546011)(9686003)(33716001)(86362001)(44832011)(7416002)(2906002)(33656002)(5660300002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?R1VlcnFTL2pRK0JxSmRVUzNwT2tlWlBqTVVGZVQwSVVXNU1LSXlmd0lqVzhP?= =?utf-8?B?OXJBV2ZaSHFlK1dwWU03UzRmakFXb01TV2dZY3MyNzdLRkFBVzlzRHR1d0xK?= =?utf-8?B?dk9CeFo1Qmx3V3dpNzhQQ0Evb0dlMWVVUEt5aXZKcVM3MlAvOG53WW1TS3Ar?= =?utf-8?B?aEQ4eXZCd1dIdjgvQWJkUHB4djRPcWFTbk15T2ZJQXg4UzRDMDdkMWUra24v?= =?utf-8?B?Qmp2YjZ5dWpDZ2lDWGdWRTMyR2tDRUtVZ0UxSUpadkNHUFQrZzVZVFdteVZm?= =?utf-8?B?ZFdQTjBvTHRMcmpiZXFxamlmUnJERVpVS3owbU9RY0tMWE1wYXplL0FzWi9t?= =?utf-8?B?K210ZVJWYXRTaU9lcW9NQWRMR2U4eTRwNGlIRE9mNzdVSUZGK3FaRmdMa3d2?= =?utf-8?B?Z2lnNktLYmtlcHBJMXJTYUhISFVTQ2l0WUlsYkVPeWJ6djZOMkVNWG1TNVl3?= =?utf-8?B?eTZxa3dRbVZOUHdvWER0ZXhlSms4MlRuVW9odisxZEN1cHNSRzRWZENxdWlh?= =?utf-8?B?OVJSUEx2b1FsVW5ETlJCbmJLalJUemtkZkN6c0M3SW9RQmRPaVY3V0k5OXo2?= =?utf-8?B?TDkzcU1MNkoyTisvN0dvNjVSVG1remdBR1R2ditYR2dWZVd4cElxb0tPTEVP?= =?utf-8?B?YkdnZ0tZMEZJYjhic0FGV1J1TVJzb2R4NzlRdWlDemNxT0g4RHdqK1NoLzlE?= =?utf-8?B?dDM1Y3RqRG9WekZMQk9CRGtLek5zc0pVZjhNcjlGa2xjQ1h3ZkZYRTExVGlZ?= =?utf-8?B?QUE1d0JrWHZaVHM5a1RHUFN2d2ViZVltN1lIVUlCM1pFUDdsbTNzNWcyM1Js?= =?utf-8?B?bERmbkRZcm5BNC91eCtJUzN1S0xUeVhiZkNML1B3bmY3eXN0L2JtUGwvMG55?= =?utf-8?B?OCtVL201QXgwQWVtNmRkNFEyY2FpMFhxcGtEMnhUQnB5TCswU2VBZW9Mc0x0?= =?utf-8?B?S2RiUkdOZzl4NURLaFZ6V1FHRXZhQkRBOEJZditBNnZobE1XMHFCa1EyMThD?= =?utf-8?B?ZVUrdDZUc21WUzJVWjJsY3RvTDB3TEhqOG94alNpK3lyUHZTNUxzK0JzTDd4?= =?utf-8?B?Y1dqK3J3b0tLUDlLbC80VEM2MjI3OHZlMTZwREd2YXMxa21jVml1U1hZcWtP?= =?utf-8?B?MFJzT3B5MWhSYXNVbzZIVzNWcXBQRDVGZTR0SUhWdGhEdTBvRUNGdzJDMEJ6?= =?utf-8?B?VEpNUHRrQXFSWDdMbGpxektMdTFoZmFRMXZuSGhCS016ejlUcmtBM2g4VnRl?= =?utf-8?B?WDhGc3JSMWRldGkrS0NVQy9KOHZXQTI1VDFqNUhpSFpNUHdrNXFqVmNjVHdS?= =?utf-8?B?L1FTTTdBMzRDYytLK3RHb1VrTklyTjZmdDJiSkZVTVgxbmdaTzUwWXN1Q3hG?= =?utf-8?B?eUhSVHJKdFVjN1BMWjFaL3VEZXlPNkR1LzFnZ2pMeVo4aERZWUpWRUFXanc1?= =?utf-8?B?VnpRQ0E0YzNON2p1NEFLck1KaHRYcmR4R2xxcVEzeitPQnRuVVB3ZVJmYjRn?= =?utf-8?B?WTZNbllqSHZmL21sMUExZy92RmJ5TVV6bFcxOEJQWENuekcxdmtFWk1ET2Y2?= =?utf-8?B?UnZrSm10VVpiOThNWnFQY3huOC9IYk1qcGhmNVF4ZFVUQlN6bUNLWmpubUgx?= =?utf-8?B?TUp4MlFSQitVU2NKQ3ZKOURmUGR6bngxaUNPL3MvbGhXM2M0Z1ZpNzdCTjR5?= =?utf-8?B?M0Z0N1ZnRWx4d2pwbmZjSWt5dTVrYi84UlFwZy9sUU9MU1VpNURzODV3Q0dQ?= =?utf-8?B?RlkreEdUMzFsbmdkbHJiVmtkbG02THpaQ1BmVkNOTGlQa1BYeG1POThlcElq?= =?utf-8?B?WVh6dVZodUNTcHptMjdrVGpldmxUZUk3M1JqVlAvdVJuZDJNRG9oMHVoejFo?= =?utf-8?B?c0EweGt2M1lxZ2xRVzV4U25SVloyamdiM1g3cXk2U3lFM09oT20weG1lUUVo?= =?utf-8?B?UGZXS2ZqOGlKYXpCbG93N0g3VlgrR2dUckJwWm1tUTVhVWRrWUJVTGtoSmt1?= =?utf-8?B?alVTcEluWVVBTVRoU3dZMWhnRkZXMW9scmt2ZGluaGQzaDl4WHE2dG5mWE9G?= =?utf-8?B?ZU1qR1JseUZGM1hOT0pwMjJ2Wks0NWJVaUQ4SVUvcWdjOW92SG1Pa2FTYUhy?= =?utf-8?B?dEhpU1VjUURrMklsZXlscmYvZ1NQM2R5WUZ2NmRDTWd3Tkc5V1I4c0ptTkJG?= =?utf-8?B?YkE9PQ==?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: =?utf-8?B?UnFTK1hkQ2NhYmhNSzV0SVlPQ1hoQVpObVVuWSt6SE53L3pOc1hyYzNlUlNk?= =?utf-8?B?RWNiRmUrU1ZIaUJINVg3eVB1T1N3eGowVktzNVVSZzhZeXN3WUk1WjFXN0RE?= =?utf-8?B?N002Q2lCS2xzbDJUZmRZbmtjemg4VHRjU1ZVVE5uMFRHYXR6SXJQM25wbGRI?= =?utf-8?B?TXpoNFQwVEJwcDRLTUpPVEhEYjMzeXpibitWK01mMXdrZEVjUFpCdkREV3R4?= =?utf-8?B?V0lXUjZxSnFJOUNIOXFOM0dGbVJIM3ljaFZQelA5VWZyS0I1N2VENGV0a1B3?= =?utf-8?B?cXlEUTVUc1J3YWZicWZROWY4RzlkYnNHaGlReCs1ZGF5ZHJwTndsMVNlaUhW?= =?utf-8?B?QVZoTCs4TlRXSEtScU5SZW9rcEF2ckxoOXlQdVlKMGtGTUk2OHNQYnFpVUdH?= =?utf-8?B?L3cyaXhnUDhzK3NqbkF2Q2ZZeE5qdXBCRGkySm1yVWFkSnRKZUJzRWxvZG5B?= =?utf-8?B?c2ZRVUZqN0FiVFRaUmNZRVljQjkxVmwrb1RodDNIMktWTGdyZEJoQmdQZFpG?= =?utf-8?B?MTR6UFZZZTNkc1pkMkFxbGlBc05mQ0ZFTk1LWHZrRVRGMDB3T1BnSEJtNC9G?= =?utf-8?B?NFVFNWFEZnI5amZYbG5BTTRGbHZ4VDRHTFZyZmlGcW5jQW5DZ1RpRjhUaFBx?= =?utf-8?B?WVJ6enFLQVhKOWQwOUJLR3lZWWRWdlByMFh1RkZ4ZS9Ldjk5azFQV2YzV3VT?= =?utf-8?B?dW1tMGh6b2VhcGxxcDYwUmE0dU5saWh1blQ4QUx2TUFyMjJmZllreEZzYnlw?= =?utf-8?B?QUZUNnZucVZOYUt3cmVTclpWSWRzVmQ5TndnUGNLWjdzOFdHdjFEZHdBbmt4?= =?utf-8?B?R1NRLytLRTNnK2piL3UvdDFIZ1FYUHhGdkhWSEFIWndmUDVHay82YjhTWGdz?= =?utf-8?B?QkZZUE1uRFIrbHBCK1J1dTdrbTBmUDBmYTYzVjl6QjBkeVBoeFFJYjBzejk5?= =?utf-8?B?a3p1ZmRaTHJDUnVFM2JPdkE4Q3hpd3B3RDRWcTg2UzdyVmo3bHRPa2lhL0Jw?= =?utf-8?B?MXQzNGYzcXErdVVjZlNLdGNvSG9nR0FwcU55TlJEQ0trck91UGlLc0ZYbW1G?= =?utf-8?B?MmJWU0N5SjJBak5tNXhaM2tUTDBNd0FRdngrRVovN3RYWlJUY1BkczNCSHU2?= =?utf-8?B?MG9KUzlKQVJhQ2p0VVdTbGFQKzFYcVQ3aGlJbkFBdDcybGFRQ2wxaThEUHJB?= =?utf-8?B?YnBibTJwaENpdWlnWGZ3YUpmN0ZvNGJYbVl4dzQ0b1Rsb3orSHY4ekhlVEhV?= =?utf-8?B?amhxc2hOSDRQemhScDdDSDZKRFBiRTQwNGlaOU81V1lPcFZld2JlSUNTQW5x?= =?utf-8?Q?M804Yg6P+VexE=3D?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 26493d91-4db9-4121-89b1-08db67a380ce X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jun 2023 22:06:54.5654 (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: k2Ila3fDEHMdapev7I2MYhsaamRPPbdgzHjH4wJBZH8RfUxRH4FLgYyzqfI2rYfndqwwMeb27laf20hzbIMo6Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0PR10MB4839 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.573,FMLib:17.11.176.26 definitions=2023-06-07_11,2023-06-07_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxlogscore=999 malwarescore=0 bulkscore=0 adultscore=0 mlxscore=0 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2306070192 X-Proofpoint-GUID: eZkn1Xh55vw1YXw-M5Pi2_lS2B6PmSXm X-Proofpoint-ORIG-GUID: eZkn1Xh55vw1YXw-M5Pi2_lS2B6PmSXm X-Stat-Signature: 8e1kyai335ngyh5xs9whqx98a7d8adpg X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 52191C0008 X-Rspam-User: X-HE-Tag: 1686175649-256993 X-HE-Meta: U2FsdGVkX18HbzG5KmP0rZ+yq0jGdXsQTxdzH4vCmcqjLcB83yqO033cyNJF+Iiz/R03pdJBFB7lhVOHtBJ/DHOoXeGokhsDiy2qOxAdOwacitVh6/Z29ET6L+d+G5iUZuBLcQhm37BiXqzo2rCX51JkhygRxvS/iZZz1UlVg8Zrs9letdZeZRg7OpZUjNO6GnzbE99ALf3hwKAHUpFBOI8HXKlkUlOvsckm3O6LTF1bl8vwVXOo2eNbKJI4Inm57na/8OMzs4kkRd/u6YHsQ+Lmkm44i4gYth90+/u+XY34NQymU+8XHFO8DXuVmn3rreLrSpaxBVsTwHuCTkuYSCsPvzfXaUI6zoEVarRyAoDlOniB62kroSwroDldmLx/wmnd9gXCh0DdrNSQzHuKsYaqGFQwj5JdaU8GlZhOgEQRak+Upkp1D5ZD6Bc3R5p7D2v27zxd3vLeVjLEGIkIxkhELJEHLdEK8f08Jm/F7pH0oSJGBbGlKb+p72LQ0bIfZc2VZLl7RKT0WIQkBMQAPOwO4L9a9xu3z4nWHeV1G738KtJSYGv8+T/INXwUS43K9+HQkuxrOfYtsAMnaJmqYgYeAo8QbUpze3PLtS0CDsnhZzHMZrrAM02AufiWHZJ9XJix7mUl3O77ZrlA8+VuDODJQAilp9PqXV2gqMUNssmk/9xfcm0exl/i9K7FxbA6mB1mWFFuAxQFzHIQX9G7jjByh5WDCx1ukHhCTFIQb+t1fjYOG5q25WP6bT8zROljoCcuNWZBZU+idNx3NIamxlTNqw7xVWS9vUphZtyFpRYjbsFepnFqzLnjKSi0It95/1H/IIJ3Z8Dtnam6e9ZI3PRX/apc+h6+thcbrbe5XZmZU6BDqeu6RWxq2dRZzfZ+wIYVO1krstivSu8vRjFcvc+bF4rNmTPAws1WvzPvg4W5DrCwnkSFg/QFVTcHDLbXIhSJ8w/b3kYPqGXqcja r3g9yA5R iL2ZHD2UpWZa5uyvIq27fXsH7uY0Yk46oE+JoWQfJ8uegREDssjlNF/6Z4TvLKKK7TRYTY8y8wJVp5fU+TuVnmHgED2t9TDn2syMxuUx0UIrJ1crA98xoFwETFHMjHl1oxdV2XdmO8VM3eo/QCWoJX/z4WlRn9ytBc7YnkDJ2x2GJdLPk4R7RN7V5iNZlUhMWW42fOx1Qn3SJ0CE1wo9hHuye/6H7mmjiQoCZr5LPAW2eFyz3mXCGTi2vXJjAuBbMUnyw2bUJ+cQUlowUWvysedwD7pPUMru8XDdnclcBAi0qOHrOkrDR2+SLeR2cJJ9QDdq3WV8mpm9qpYuZ4vnPbFO9UVbg8NGNKyac7LjRDzug6yFFbZK71K1BCn33905dZDKDD4o04pTKh9o= 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: On 06/07/23 10:13, David Hildenbrand wrote: > On 07.06.23 09:51, Yosry Ahmed wrote: > > On Wed, Jun 7, 2023 at 12:38 AM David Hildenbrand wrote: > > > > > > On 07.06.23 00:40, David Rientjes wrote: > > > > On Fri, 2 Jun 2023, Mike Kravetz wrote: > > > > > > > > > The benefit of HGM in the case of memory errors is fairly obvious. As > > > > > mentioned above, when a memory error is encountered on a hugetlb page, > > > > > that entire hugetlb page becomes inaccessible to the application. Losing, > > > > > 1G or even 2M of data is often catastrophic for an application. There > > > > > is often no way to recover. It just makes sense that recovering from > > > > > the loss of 4K of data would generally be easier and more likely to be > > > > > possible. Today, when Oracle DB encounters a hard memory error on a > > > > > hugetlb page it will shutdown. Plans are currently in place repair and > > > > > recover from such errors if possible. Isolating the area of data loss > > > > > to a single 4K page significantly increases the likelihood of repair and > > > > > recovery. > > > > > > > > > > Today, when a memory error is encountered on a hugetlb page an > > > > > application is 'notified' of the error by a SIGBUS, as well as the > > > > > virtual address of the hugetlb page and it's size. This makes sense as > > > > > hugetlb pages are accessed by a single page table entry, so you get all > > > > > or nothing. As mentioned by James above, this is catastrophic for VMs > > > > > as the hypervisor has just been told that 2M or 1G is now inaccessible. > > > > > With HGM, we can isolate such errors to 4K. > > > > > > > > > > Backing VMs with hugetlb pages is a real use case today. We are seeing > > > > > memory errors on such hugetlb pages with the result being VM failures. > > > > > One of the advantages of backing VMs with THPs is that they are split in > > > > > the case of memory errors. HGM would allow similar functionality. > > > > > > > > Thanks for this context, Mike, it's very useful. > > > > > > > > I think everybody is aligned on the desire to map memory at smaller > > > > granularities for multiple use cases and it's fairly clear that these use > > > > cases are critically important to multiple stakeholders. > > > > > > > > I think the open question is whether this functionality is supported in > > > > hugetlbfs (like with HGM) or that there is a hard requirement that we must > > > > use THP for this support. > > > > > > > > I don't think that hugetlbfs is feature frozen, but if there's a strong > > > > bias toward not merging additional complexity into the subsystem that > > > > would useful to know. I personally think the critical use cases described > > > > > > At least I, attending that session, thought that it was clear that the > > > majority of the people speaking up clearly expressed "no more added > > > complexity". So I think there is a clear strong bias, at least from the > > > people attending that session. > > > > > > > > > > above justify the added complexity of HGM to hugetlb and we wouldn't be > > > > blocked by the long standing (15+ years) desire to mesh hugetlb into the > > > > core MM subsystem before we can stop the pain associated with memory > > > > poisoning and live migration. > > > > > > > > Are there strong objections to extending hugetlb for this support? > > > > > > I don't want to get too involved in this discussion (busy), but I > > > absolutely agree on the points that were raised at LSF/MM that > > > > > > (A) hugetlb is complicated and very special (many things not integrated > > > with core-mm, so we need special-casing all over the place). [example: > > > what is a pte?] > > > > > > (B) We added a bunch of complexity in the past that some people > > > considered very important (and it was not feature frozen, right? ;) ). > > > Looking back, we might just not have done some of that, or done it > > > differently/cleaner -- better integrated in the core. (PMD sharing, > > > MAP_PRIVATE, a reservation mechanism that still requires preallocation > > > because it fails with NUMA/fork, ...) > > > > > > (C) Unifying hugetlb and the core looks like it's getting more and more > > > out of reach, maybe even impossible with all the complexity we added > > > over the years (well, and keep adding). > > > > > > Sure, HGM for the purpose of better hwpoison handling makes sense. But > > > hugetlb is probably 20 years old and hwpoison handling probably 13 years > > > old. So we managed to get quite far without that optimization. > > > > > > Absolutely, HGM for better postcopy live migration also makes sense, I > > > guess nobody disagrees on that. > > > > > > > > > But as discussed in that session, maybe we should just start anew and > > > implement something that integrates nicely with the core , instead of > > > making hugetlb more complicated and even more special. > > > > > > > > > Now, we all know, nobody wants to do the heavy lifting for that, that's > > > why we're discussing how to get in yet another complicated feature. > > > > If nobody wants to do the heavy lifting and unifying hugetlb with core > > MM is becoming impossible as you state, then does adding another > > feature to hugetlb (that we are all agreeing is useful for multiple > > use cases) really making things worse? In other words, if someone > > Well, if we (as a community) reject more complexity and outline an > alternative of what would be acceptable (rewrite), people that really want > these new features will *have to* do the heavy lifting. > > [and I see many people from employers that might have the capacity to do the > heavy lifting if really required being involved in the discussion around HGM > :P ] > > > decides tomorrow to do the heavy lifting, how much harder does this > > become because of HGM, if any? > > > > I am the farthest away from being an expert here, I am just an > > observer here, but if the answer to the above question is "HGM doesn't > > actually make it worse" or "HGM only slightly makes things harder", > > then I naively think that it's something that we should do, from a > > pure cost-benefit analysis. > > Well, there is always the "maintainability" aspect, because upstream has to > maintain whatever complexity gets merged. No matter what, we'll have to keep > maintaining the current set of hugetlb features until we can eventually > deprecate it/some in the far, far future. > > I, for my part, am happy as long as I can stay away as far as possible from > hugetlb code. Again, Mike is the maintainer. Thanks for the reminder :) Maintainability is my primary concern with HGM. That is one of the reasons I proposed James pitch the topic at LSFMM. Even though I am the 'maintainer' changes introduced by HGM will impact others working in mm. > What I saw so far regarding HGM does not count as "slightly makes things > harder". > > > Again, I don't have a lot of context here, and I understand everyone's > > frustration with the current state of hugetlb. Just my 2 cents. > > The thing is, we all agree that something that hugetlb provides is valuable > (i.e., pool of huge/large pages that we can map large), just that after 20 > years there might be better ways of doing it and integrating it better with > core-mm. I am struggling with how to support existing hugetlb users that are running into issues like memory errors on hugetlb pages today. And, yes that is a source of real customer issues. They are not really happy with the current design that a single error will take out a 1G page, and their VM or application. Moving to THP is not likely as they really want a pre-allocated pool of 1G pages. I just don't have a good answer for them. -- Mike Kravetz