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 0DBA8C0015E for ; Tue, 1 Aug 2023 18:49:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 508AE2800ED; Tue, 1 Aug 2023 14:49:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 492122800C8; Tue, 1 Aug 2023 14:49:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2968B2800ED; Tue, 1 Aug 2023 14:49:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 117052800C8 for ; Tue, 1 Aug 2023 14:49:55 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C841240BEB for ; Tue, 1 Aug 2023 18:49:54 +0000 (UTC) X-FDA: 81076425108.06.05ED1BD Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by imf19.hostedemail.com (Postfix) with ESMTP id 2FA381A0002 for ; Tue, 1 Aug 2023 18:49:50 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-03-30 header.b=inHJhZ30; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=SpbnKimj; dmarc=pass (policy=none) header.from=oracle.com; spf=pass (imf19.hostedemail.com: domain of mike.kravetz@oracle.com designates 205.220.177.32 as permitted sender) smtp.mailfrom=mike.kravetz@oracle.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690915791; 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=SnWbYGgUiIwQf8ET2tyVtBU1KCp6CLaXQfmmm/EfBdQ=; b=6+6psjt8048gslt2aIu9u1QMA+x/XISssR0iKp0AhKHQLwUcX73KCaESRvuo31ISgtkiob B31gwv4Vlj8XzRCK6VdxvfLE7/gvyeaddLDDmagkGf5wNSbREkAMLrn+yv/UzecMguj/6H QtkA027Y5WtLOx98Q/tUizAQo1DQt2w= ARC-Authentication-Results: i=2; imf19.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-03-30 header.b=inHJhZ30; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=SpbnKimj; dmarc=pass (policy=none) header.from=oracle.com; spf=pass (imf19.hostedemail.com: domain of mike.kravetz@oracle.com designates 205.220.177.32 as permitted sender) smtp.mailfrom=mike.kravetz@oracle.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1690915791; a=rsa-sha256; cv=pass; b=XcXXZHP28wW5BYYG/h9cLUmcHjeCaG5fuD4dEdmY7/8LQLpi0IkywPX25c6SZjZ4VLNqUv y3M0LrXPbrmPEIgNwWSvATpldmGZSulxIbDZkg53lMK1fn9R+9y1vs9XJol8DTXe0aqyzk hjbLLJgtoov9gMo+GhFPVEBE88cRAJc= 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 371Ii5tb005392; Tue, 1 Aug 2023 18:49:50 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=SnWbYGgUiIwQf8ET2tyVtBU1KCp6CLaXQfmmm/EfBdQ=; b=inHJhZ30irG2k4OQTFZK3kOI9UGN4BptVugS50rvh06JXOkZ6dBcy8kodB0K3FxB1Z8+ CS3ZxZD7tDa+JK2ufx4BkYkFiMZvLWW82cB8MuflTzF/eTp09oBUiOdy965Cyx5v+5h3 cNFGIgXLCgOxW1qtx37PjQG7SWnhVBZVTqL9HaTqlQYxjqGyoSq8gJ3izE/CD7R9BVMG kaDY0qquSZXUVSGkZLHjTJ45QXjCxDBjli23Pq+CFFKTHTxkEJ/oPL6vFZep/VxnnkQ7 nzg3wSXazZGgIxULepMyKxj7j82UIGx8j3bEM97b6WtRr95K/JtRMMgRH1wjLc11kcsS bg== Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.appoci.oracle.com [130.35.103.27]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3s4tctwmq8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 01 Aug 2023 18:49:50 +0000 Received: from pps.filterd (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 371InJ2Q008610; Tue, 1 Aug 2023 18:49:49 GMT Received: from outbound.mail.protection.outlook.com (mail-bn8nam12lp2173.outbound.protection.outlook.com [104.47.55.173]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3s4s7dbu23-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 01 Aug 2023 18:49:49 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P8E2g1kxqAOBeHONph3/VZeYpg6H7j9zZORTSVVLDKazS8etQUIOQrdA5Ulhl/zwhqKlf/k3Xa/D0UWiB8x4KgnBnSajGSZoFM8OBfP0eq2JJPysp3240CBmL0RDAG1Baca5w+D51VT4fjZ9j1stWzAnzQFk2nwEMwo3V7sFMXnWVxW7lHwYfxsGxpXf9/Wy6U6JtBS9CTzU5qlj2gNvtIpfpgM2Vzrpf7p+2niFLLvPiWJYHcEWDRkMnUlDURIOW6doDXe33WxXL7nMp9yF3Yt8NnmLZplZAOLH0hvD5OfEFf2FuLX8JhyJOhxr/bOSbnWWVITnWbh3X0Gr9dBHdw== 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=SnWbYGgUiIwQf8ET2tyVtBU1KCp6CLaXQfmmm/EfBdQ=; b=MOdCwdkd4CoNnkxQtRdZ/w9rZgN4AKPsodQ2AZsk2e2LSV/0DG8fwzcC7EL3kUoe/y0DN19Q9ccuVJLypTY23KVvbW2aWWvdffR4gd/AbFW4jEdn4bWnJ2eVFlflPScIpsHb50WrgMniFs5o+ctjOabqa2jo2RGUDFh7ytdRECRMVPq44oMNfvEXd8JUAKj0rrmHF274JDZ6lfGXJKMgIgVMAS5CcF/7lQ0uGPv/OcsWztaaKwSBoVgLluBoJ3e6hbf2koqhSqP4XzyCkG2QGf4jDsOpKNe1jXoEEdbeDsqBT+WleEHUTtgTdRFmDQGx/EmiFdby0+0jbToyiEAHzw== 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=SnWbYGgUiIwQf8ET2tyVtBU1KCp6CLaXQfmmm/EfBdQ=; b=SpbnKimjNSVE+P5OAV6i307tHis7H1HN+nZhKWX4XjxwrnJXboHztOXralS4MlI6Q2YK5Pykt9lmn9mMlZbJxDVB3Y/EjTjuD+/RR7fDeh4l3mxdJCRrPTg00tTxzmIn7mdjhat7Lbyy9Ccelb8GVjlOiGrmbEz5S6YPGA7ZC4k= Received: from DM6PR10MB4201.namprd10.prod.outlook.com (2603:10b6:5:216::10) by CO1PR10MB4706.namprd10.prod.outlook.com (2603:10b6:303:9d::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6631.45; Tue, 1 Aug 2023 18:49:46 +0000 Received: from DM6PR10MB4201.namprd10.prod.outlook.com ([fe80::8057:a3e9:cbd1:252a]) by DM6PR10MB4201.namprd10.prod.outlook.com ([fe80::8057:a3e9:cbd1:252a%4]) with mapi id 15.20.6631.043; Tue, 1 Aug 2023 18:49:46 +0000 Date: Tue, 1 Aug 2023 11:49:42 -0700 From: Mike Kravetz To: Xueshi Hu Cc: muchun.song@linux.dev, akpm@linux-foundation.org, linux-mm@kvack.org Subject: Re: [PATCH 1/3] mm/hugetlb: fix the inconsistency of /proc/sys/vm/nr_huge_pages Message-ID: <20230801184942.GA6544@monkey> References: <20230730125156.207301-1-xueshi.hu@smartx.com> <20230730125156.207301-2-xueshi.hu@smartx.com> <20230731221725.GA3351@monkey> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: MW4P220CA0024.NAMP220.PROD.OUTLOOK.COM (2603:10b6:303:115::29) To DM6PR10MB4201.namprd10.prod.outlook.com (2603:10b6:5:216::10) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6PR10MB4201:EE_|CO1PR10MB4706:EE_ X-MS-Office365-Filtering-Correlation-Id: 21267eec-20fc-441a-0f75-08db92c01349 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: s4Vau4lDHfy9lzbePTjD33pmHCnUuOFIFN908uqGFvoGHNGivQ+Dz7yg1IFPIuJwBHqYmIiWvOOiICMcQiOlUVu6b+DihsFVjllL9b6c/CsUTzUiXm4kWiY9oRM4gVzOZ/FcUi9yhG0rHA6svOmZmPDqW5Aoaf8R2Yn4247ZQRn7Fn33BuBBfHM5UNHRZSm++fVz6nVoVmMT4urkbcspuXqy1EDwCwNCO5lmENaAbyq92gNdQz95o6MElW2Wkze+ZWm+5NtH3BNeW9hja3eoZGzOiNylEzb9xdMCuk++1r/AUU0GApk2g2aDUv7bIMwulbjvUL+0nYDJhRDVr+VkxuoGoKVADOwHzN9E4orqpMTijRXBINeYJe3vtmeZAuddLIAM4re9tGmi75xco5cmDyMmDJQcOD1hNdssWy+wfSLz5yrgvEDcaRs9DVHUeky28kD+X4w34iy5A9wHpanty6eTUhs2zBGA/sH2146sC76DsBVOnICH6AYH2aKKFoqQyU4UdzcJmiR9f8JlgyM+1Be/AMhk/fbpqJMHsNJWRJdgBsJTMhzE0y2bGdiIz1faJ98ftdwtTaaTYTwsDTFwNaId/5oaAg5HWVzwEfOolTU= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR10MB4201.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230028)(7916004)(346002)(366004)(39860400002)(396003)(136003)(376002)(451199021)(6486002)(8936002)(8676002)(66899021)(478600001)(6666004)(316002)(66556008)(66476007)(66946007)(4326008)(6916009)(83380400001)(9686003)(6512007)(38100700002)(41300700001)(44832011)(186003)(53546011)(5660300002)(6506007)(26005)(1076003)(86362001)(33716001)(2906002)(33656002)(14583001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aHFOeFUwdmVQRFFxSy9IbSs0Mm5mRkh0NXBNK05ZcEV0VEZtRVlwc2pEM1VJ?= =?utf-8?B?d04yMUlhUjRmMVRCQ2p3MFp6UUJLSHFISlpVY0d1WEowNHQxOXFlZnlFbmU5?= =?utf-8?B?QUJSbzFSZkw0RzZaajk1OHp5MTRvdHBpeDB2SU93Z1VMby9saFhIQWUzMERL?= =?utf-8?B?TlEzMFQxRVRMTkIvNGF3ZllnT0p0c1JEQjF2c2wyUStIa0JtQzFsSDB5Y2xU?= =?utf-8?B?cEJRV0o1VUZnWVV5MExGRVMzSHdFSTM3alFtUEdqcHloRktmYWVIV0lRTEJv?= =?utf-8?B?ODEyQ1ovUjFXcU1ONjl5MXArQitaSTRLQ2VWSWRzSHpxSzF4eVVWaW83bWFB?= =?utf-8?B?ZFFvdlNrY2JHVWhDR1lVd1RFMVlWekMyRzR1ZXRXRFZqbXZCUnk0RlNrM2wr?= =?utf-8?B?NkN0UmRITFN1K0EzQ2twSGR4anloWW51WWVldk5OTFNtS1BPRWQyUHBOS3kz?= =?utf-8?B?VndZR0dnbUsxYXB0cHhEL3ZvNG1oMTN4K3o3ZlduNTlWNHR2MFl6OHgrY3Q4?= =?utf-8?B?TkpHQUFQUEYzb3hBRmQxY2cwUkI1dlhyTVBsRDc2b0NqSStCbTk4TjZ3bEJ2?= =?utf-8?B?NUF4aDNHcERuNzB2UU4rQ09pZVYwUy9ZdmxqZGI1TURXczVJdUhRTWFxM0JS?= =?utf-8?B?RlpxeEVZUHJ3cmpEVDYxM1FwZlFJRVlUc1c5d0s1NVlDTUZ6YmFzeFhsRXZp?= =?utf-8?B?UHh6ODhQLzd3R3NPRm1VdWRBdUk3dXJadHhVLzlRb3psUlNEdEJrcTFyUXlN?= =?utf-8?B?b0swYklPbGJJblV2ZHhnZzFNeHV5SEwxVWdCaHBhU1ljRlVzK1BiUyszYzMx?= =?utf-8?B?emdndm5xRnNMZUU3aFhUemYwbFhUWi8xWGFnUGJyVG1iRXpmSWFxbURTSlAv?= =?utf-8?B?YTQwQVUxbzZWWW9iVWJEVnpVOUNLWW9tWHc5YWVodXM5aTJXbG1Vb2dvRmUx?= =?utf-8?B?SVlNOGYrbGN6KytxWlNOQUZEQXJaTHY2M1ZTRDNuWWZXZFpHN3RJdGNWVldP?= =?utf-8?B?aFVtbWpFYWJvRnR0dlZwTWlrQW9RWXlKVkZRWnc2Q2szRnBsbDIreTJ6OVF2?= =?utf-8?B?M0hoc3RiYUJObkRWRWYrNjF3TGR6Qng3Q1E5QTdNV25vSkpzd3l4VEdmNUdX?= =?utf-8?B?KzZSdUpjdXdTYzZDb2ZXaU9xZXlOYUE4bm1VYXRsalNoQTBJZmRLSXZpd3lW?= =?utf-8?B?Q1owcFJpWGNkZjU3cUhTRisrVHFDYnV6V3lIb2JHeHdhbE1KY1ZHTXNYTDhM?= =?utf-8?B?NmFoYzN0MlByMWt6V1V2dG1tRWlpMk1UdXFqOHN1YUg2SmlWRjhKYVVsY0RJ?= =?utf-8?B?aE83VWFzQXdLdEN5N0Qva3hZUjhJSHc5OE42UzZlRTRoOUI2bnJhTm1GamVh?= =?utf-8?B?ZVFtVnZQQ2hyUmFaMU9ZTzM5UjRCNE5tcnJwZ3NpclBEbVhkeG9RWm9ZQnZB?= =?utf-8?B?aXVWV1hvVk9yc29LVXVidzlDbDlMOWpqbndNNGxXQksrWS9NRE8yU1dZSmIy?= =?utf-8?B?ekpDa2JhRXFxNkFJL1FsS3RybURKOVpzT2wwcENHREVGVHo0d0EraHdaU3cw?= =?utf-8?B?ZUl6U1ZZSGY1UWs0Nzc2RVRqMjRUS3ZqYk5MbmRUcXZaUVRqdXFGTllwL0Jx?= =?utf-8?B?ZkJHK2VqdDdkNWh5MGltUHNVV3Y5M3oxSzU4TExrUjJhZUkvNzZjZGNxQXh3?= =?utf-8?B?T1B3TWhMVWVLWTdPalpHZUFHT3F3L2VtcUpIbEtFRFJKQm94V050bHpieFV2?= =?utf-8?B?Y1praWZWdkdEQkh2WHFGZ2xpRXptTDJLR3p0U3VINlZlVTNmN25UbUxFWVp1?= =?utf-8?B?NktyQlBjaGxCZTdjektsTjhUcXFaUGpOZnlmY1J5dFFzZUNMSXlFbmZVcDNo?= =?utf-8?B?dThodTJ1UVFBSXFtbjhHV2VFbG1wZ0w3dW56SG5MY3RmWEpQZys3YWlkR0Ew?= =?utf-8?B?U3hWZE9iRmdublY3cVE4R0V4NHd5OEo3VFZvaGZWVUQrQlVSem91ZjdPbEFz?= =?utf-8?B?ZllrcGFSNk1pNEkwclMveUI0bUlzUDh1QVR0T1Y1ZG51YklZYlZOU3NwVHoy?= =?utf-8?B?RVJ0OHh3M0NEaWdPWlIvUFhIL09yU2M5UzA0dFgwZ3JaUGRwbC9xdFBWWjJw?= =?utf-8?B?b2RnWU8yVE9HUVl2Sk1TNjA3bDREMFdoNmhEMzNUNkp6YmFGbGd4YURwZVdG?= =?utf-8?B?NlE9PQ==?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: SLY+7KCFFVLS2jvXqAoCNW2sD/IAMiQa6bBJknjDplZkLu3TB6iXUepAxwQytivV6M8mPznmxcA+cc1NZQLwYq07HLAszQoSku77U3dqt777iWMp9IXecprw7prJNxNVzeXxX4wNRixPvzoEpPSftXANIswIyBQ+dr3ZzuAJeLD4wUtB/0IlCoEC2TMn9GmQHdc3Z6zs7opE6zo/pe1gH7s/hcwvE/U8CiMBxVvSWJTb5DCVjAAvtLx7pFiv0roGMaMtSg93AAJe4SrXafEqE34A+IPyt4dhDMqkAiW9JjLRuX0RJq+RSBuIoKgoytGobxdnNrYQ8olBjE+wSl1WBbJurru74p4eAR7N86vt+RLGkaFkgEPuqSzfnLLQMS7pc1UEEEC6cumGyDqNPhBiCK31ZzI4JCEycEVROrX2vtzS5LZPtzezpdIZqd5cjGVbCpzHv1xA6jDslGg4CNkNmwuo4DAyaQ34iXzyJ20B8PS3uDPSr8XyIpDxKny/eP6HVSpuSMfAOLgBJhjhztK0xaFw/hrA5Fe/pdJVfXV8kfaWxqmiqdMI7YZBjXy9m2xjFSp9OArdy3FDq3dATWs/0n0BV7wR9dcpxtR57mZkgD1y8nOsuIQ5+YQq8IlxuyvOA8lcKJrwcoU8U7beKjJ9RKhY0ZZWv1E8Q2m/mXv/h14pApKGYSzXjW6P2eI0IJVKsFafOiuk1EYDl2l4I58xGnRRkGQOb4AuwihcfZqBQUOLMQcLmZxiSytHQnoabJ48w7pWQWpzQpe9lbUWD0Wp2vFg9dGHB2gfnfPfzHIg3BxJ9nU7UWwYi12cR7cIeF/3Jie1Q9MZM+zutlsAJno8ydWhVadesMoWPeIpWMmfpjs= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 21267eec-20fc-441a-0f75-08db92c01349 X-MS-Exchange-CrossTenant-AuthSource: DM6PR10MB4201.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Aug 2023 18:49:46.0709 (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: Z/QXmSHcmKliWITJFnLv2T+8SxK4z1bZDcQiob941kIwZE37ZxPqFiB1CVj4rJmdLwkb2V9vD4+y8zEz0r+i2Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR10MB4706 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-08-01_16,2023-08-01_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=999 phishscore=0 mlxscore=0 adultscore=0 malwarescore=0 suspectscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2306200000 definitions=main-2308010169 X-Proofpoint-GUID: 6MPG-zwNdqh2fDsKENTdFG7HETklFQPm X-Proofpoint-ORIG-GUID: 6MPG-zwNdqh2fDsKENTdFG7HETklFQPm X-Rspamd-Queue-Id: 2FA381A0002 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: gj4enyia3g1iuzdztfhidepdd5qjcrf6 X-HE-Tag: 1690915790-941497 X-HE-Meta: U2FsdGVkX1+JD6GGrDDvMKkoN9ut6zU+4xpIQqP5s6Jfix78QBvnFuby4ndbP4Tb2DIJcKQBmjGy6Ps4Iwvo7LATh0MCiEx2yxg3dhtut7GmgUnCiwlvk4zWgQTvxEaP8UQdnuo6Ouh/D8Oebm8Pn1DMmItw/+8U3BAh3X+2GnBr37w1EdZRyMfo4m6k+YoV+w6JNV6e5NhPjeEmoSW+J7aPqC/6yz1geog+YHXglAaGyL5gW1YDwN+4VzojNWZe05vaC7M7dH/nus31bmCvcF9sZ11oz6OgX+Fg3NPhpPTDW+TeXXK2A6UVQ1CP9ER2sD3FTyrlHxvgbk1FdVak3bs+ZvJVlkcfdJ9vttgdq91P77aNdbdrhZjGRjGoL+Y2acaRsejgTS7Z3uvQ1aZMPrubPHsavATp2JS9KFscdhMzcIUKGuIyjj0A3TUGCs8el4nxk32zJDzME8Asix+rg9Dg+/C1Y5J+it+fdeSeKrUvPZzfJGsqnvib3tqS9DBw8GDspaHTgI7McrPs0JDEhOwE6yTUDi4oatJfi+NlrfhCf948q/l02nAWkDUeIZ2oFmu604lCaH7aOiaEEafnxeSXlrFB3J8lOOlJZR8ueOUHLze7qwBKIjvf0icGaHQ/xNmQS5KwR8xjUTyJ9zAD1bX7tBr9pqosgd1SRVeik7+r9Fd2zxt/bfFQv9NyHfrWhNH9L7O5gJxJ4P0j22dX0U6QDQbdNr1gIq1oAW++ZGIuGmJh9g6YEDUsoPzaEYVVcH0mV8tJaCDHt1lZML8CQha1w3/UFz8nOYMaykRJNp54HQRM7qVZ4ClfemCFGcoEwBGlmEwJLn+bA96yJlIsttCh8lyDfKqKRaJyg9TIcwqWZ+zF/g7gGYOquD6CwI/AArBUMMIwcptrlg3aDIiMBmT1DZlE3CsehZ9OUcy6Fx7Et9bplBtNikr68G8q9hJczRmxb1D9K5+dTwJojFw j89Ab4TS 1B1xnuxnDMK2ggLxKdWPfkJrrZIQhTiL9Vk0dUepE5gpEdgLCkL4TchVal9zSsFbGGIkeWcg5cvBabRodPNlj0ka3clY4tVtM1L87TdFNEEuqokaWGnAhWDjwtWqvn+3j5yPxva8B4x73eLW2+NkF4I6OsM3lBB/w9MWtrweOn0yjXaVKFjDFuH17LMozS3zEaQqjAn8bmi6poKVDuOUWbB6RxTKAxIbVdVZfhhfMeXpT2TUbwlhlCkseE3Dmlu90CFnF9YqihM+5rKxvyynil5cBLzpPbCLeSo9y0L50s/Y76e8GYscn4ooj33PjVzHr6PFtQtI2HMdnLX9fO1Mx03WSxOdwg0G4g2DoOfMJQdc6Ea7XQJOtrVtC4KUDQ1ZYXCop2b3aDCH5VwneNU4mrD6K8irRxgFIVZ3wE6pkT+TNj9Y9YCLe55lHIQ== 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 08/01/23 20:22, Xueshi Hu wrote: > On Tue, Aug 1, 2023 at 6:17 AM Mike Kravetz wrote: > > > > On 07/30/23 20:51, Xueshi Hu wrote: > > > When writing to /proc/sys/vm/nr_huge_pages, it indicates global number of > > > huge pages of the default hstate. But when reading from it, it indicates > > > the current number of "persistent" huge pages in the kernel's huge page > > > pool. > > > > > > There are currently four interfaces used to export the number of huge > > > pages: > > > - /proc/meminfo > > > - /proc/sys/vm/*hugepages* > > > - /sys/devices/system/node/node0/hugepages/hugepages-2048kB/* > > > - /sys/kernel/mm/hugepages/hugepages-2048kB/* > > > > > > But only the /proc/sys/vm/nr_huge_pages provides the 'persistent' > > > semantics when reading from it. This inconsistency is very subtle and can > > > be easily misunderstood. > > > > Thanks for looking into this. > > > > The hugetlb documentation (./admin-guide/mm/hugetlbpage.rst) mentions > > the term 'persistent hugetlb pages', but never provides a definition. > > > > We can get the definition from the code as: > > #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages) > > > > Further, the documentation says: > > "The ``/proc/meminfo`` file provides information about the total number of > > persistent hugetlb pages in the kernel's huge page pool." > > > > "``/proc/sys/vm/nr_hugepages`` indicates the current number of "persistent" > > huge pages in the kernel's huge page pool." > > > > "The administrator may shrink the pool of persistent huge pages for > > the default huge page size by setting the ``nr_hugepages`` sysctl to a > > smaller value." > > > > So, the documentation implies that these interfaces should display the > > number of persistent hugetlb pages. As you have discovered, all but the > > sysctl interface (and /proc/sys/vm/nr_hugepages) displays the total > > number of hugetlb pages rather than the number of persistent hugetlb > > pages. > > > > If we wanted to match the documentation, it seems we should change all > > the "show" interfaces to display persistent huge pages. However, I am a > > bit concerned about how this may impact end users. > > > > There are two types if inconsistencies in these interfaces. > > 1) As this patch points out, not all "show" interfaces provide the same > > information. sysctl (/proc/sys/vm/nr_hugepages) displays the number > > of persistent hugetlb pages, while the others display the total number > > of hugetlb pages. > > 2) The show/read interfaces generally provide the total number of > > hugetlb pages, and the update/write interfaces update the number of > > persistent hugetlb pages. > > > > Both of these situations can lead to user confusion. My 'guess' is that > > this has not been a widespread issue as most hugetlb users do not > > configure overcommit/surplus hugetlb pages and thus total number of > > hugetlb pages is the same as number of persistent hugetlb pages. > > > > Right now, I would suggest making all these interfaces display/take the > > number of persistent hugetlb pages for consistency. This also matches > > the documentation. > > > > Thoughts? > I am concerned that modifying it this way may result in an weaker control > over hugetlb pages. Administrator will no longer be able to increase > surplus pages through the nr_hugepages interface. > > Since surplus pages depend on the state of programs in the entire > system, adjusting nr_hugepages may lead to an unexpected number of > hugetlbs allocated which may leads to oom. Sorry, I am not sure I understand your concerns. Currently, the interfaces to set/update the number of hugetlb pages use the supplied count as the number of requested persistent pages. I am not suggesting any changes there (except the bug in node specific code you discovered). Rather, I am suggesting that we update the interfaces which show the number of hugepages (nr_hugepages) to display the number of persistent pages to be consistent with the set/update interfaces. > About the definition of /proc/sys/vm/nr_huge_pages and meaning of > "persistent", the documentation is kind of ambiguous. > > The documentation says: > > "The ``/proc/meminfo`` file provides information about the total number of > persistent hugetlb pages in the kernel's huge page pool." > > "Caveat: Shrinking the persistent huge page pool via ``nr_hugepages`` > such that it becomes less than the number of huge pages in use will > convert the balance of the in-use huge pages to surplus huge pages." > > "The ``/proc`` interfaces discussed above have been retained for backwards > compatibility." > > The ambiguities are: > 1. HugePages_Total in /proc/meminfo is actually the total number of > hugetlb pages. Correct. Although the documentation states it is the number of persistent hugetlb pages. meminfo also contains the number of surplus huge pages. So, it it possible that one could see HugePages_Total: 0 HugePages_Surp: 100 Ideally, one would want to know the value for overcommit hugepages as well. The sysfs directories /sys/kernel/mm/hugepages/hugepages-*/ contain both the surplus and overcommit counts. node specific sysfs directories only contain surplus counts. > 2. If nr_hugepages means persistent hugetlb pages, converting in-use huge > pages to surplus huge pages is impossible. I am not sure I understand. When writing to nr_hugepages today, it does mean persistent hugetlb pages. Are you suggesting we change it to mean total hugetlb pages when writing/updating? I do not think that is the case, as none of your proposed changes do this. > 3. As you know, backward compatibility is not retained. > > Given that the document needs to be modified anyway, why not make the > interface more user-friendly? In any case, I agree the document should be updated to match the code. It should also define persistent hugetlb pages. Thank you, -- Mike Kravetz