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 E21E9EB64DD for ; Tue, 8 Aug 2023 02:28:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 79EB96B0071; Mon, 7 Aug 2023 22:28:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 74EF26B0074; Mon, 7 Aug 2023 22:28:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 616D38D0001; Mon, 7 Aug 2023 22:28:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 502CD6B0071 for ; Mon, 7 Aug 2023 22:28:48 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 1FABEA0102 for ; Tue, 8 Aug 2023 02:28:48 +0000 (UTC) X-FDA: 81099354336.20.BE0AE72 Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) by imf29.hostedemail.com (Postfix) with ESMTP id C4E7E12000E for ; Tue, 8 Aug 2023 02:28:44 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=smartx-com.20221208.gappssmtp.com header.s=20221208 header.b=BoR+Mi3T; spf=none (imf29.hostedemail.com: domain of xueshi.hu@smartx.com has no SPF policy when checking 209.85.210.176) smtp.mailfrom=xueshi.hu@smartx.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691461726; a=rsa-sha256; cv=none; b=RY3mA8NDtSKW94AXd0qVw8NpeA8qx2yUp1BPB4Pq6tyBSsSNsJVTgJE1uT1knpyFI5MuMu fVJdznwXZATjM0l4szVN2ML2YPxQUYwRDQyNmea5OigL1oNNRQ7PTqYLQoaoC5lfmIatnr cmVhUInbRIbKyjDbKGSIGZA4bCXMMTg= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=smartx-com.20221208.gappssmtp.com header.s=20221208 header.b=BoR+Mi3T; spf=none (imf29.hostedemail.com: domain of xueshi.hu@smartx.com has no SPF policy when checking 209.85.210.176) smtp.mailfrom=xueshi.hu@smartx.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691461726; 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=+Ud/qKQl1I3YI/P0cfEf/CIVkXATPrLjOGJYQo8KffQ=; b=THbyGdNnl3OnnvSV1zWIjbJdsgHPG4uEWh9TBR0xyz+vo3yEiBBPO86R1F9W1DMaj72TRg d16YCQxng5j4lD2k/ZgSG0V84Ic6O/ksCGMlHHYtJzTcGAHkeZhODbeC9fS0xXc3LjRxBm TfU/CncD9+TdO1TBNKYOjHdGi5wKVhk= Received: by mail-pf1-f176.google.com with SMTP id d2e1a72fcca58-686ba97e4feso4949160b3a.0 for ; Mon, 07 Aug 2023 19:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartx-com.20221208.gappssmtp.com; s=20221208; t=1691461723; x=1692066523; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=+Ud/qKQl1I3YI/P0cfEf/CIVkXATPrLjOGJYQo8KffQ=; b=BoR+Mi3TGrc3v38vbeyEN3QvNzWC68TpGwRkofNOhSy4IjHgAnSO+u8n6ZppXd9B7N zkc50/3Sm8Kj5eqvxSuBRECcIAU6+gBMdyNNMQ8/G+n9eYrL0IH/afJZbuz4tRgH8tTu j+umE0r+VJsSl+iL5cC3M9EiVH9GTt8wR9la8PUl0t5J6T/i0Ygp+Aony2HPObq2QGQS zTvd+EQXPiJMJ3mHj6c+h6ub79w02bYUaJnZpieCppWJrxMXxHT9oHIqweklOl3g7uyP EP0GTg69vdVTB4pZxOQFdYq1BLjP4m7XbEKZd9sguswp1+vYKRfqTmh74p+/fImTXPJk LI0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691461723; x=1692066523; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+Ud/qKQl1I3YI/P0cfEf/CIVkXATPrLjOGJYQo8KffQ=; b=Qjkz414z4iWsHmU9KI8RBxC4iZ3JgSTKaZAS2NeQ+NZ+wDmLoDNOe5VvaXD/nrjzxG +mZLoDeFXpeV3DSgO6Mri8uG+wfq4XnDZGDxO/T4K4fSD/lkP3IXxxz6QXUbFlMHk5c2 hTHoeEMtPMbHFW5U3iNFzoaf08wcr2hevLmZfKz/sspxNkh1AkxEj3vWcXoQ6s6tNp28 HOdoRq7o0PoEcYHtFj1Vod3HbRA5+8Lo5g75WWT5LE3XYb+e4lVS/2kw4X/1TOLiL2Kf xdCbhYMlllcm7BSVUFn0W9Kfsq0gN5WE5OZMO8ZHW4khkDbKgITib+8m4OgQ42NzTQUq BJWw== X-Gm-Message-State: AOJu0Yyy4vKGyCdlfCzE+LFqZynTXCIJBXHCdgw33GwbtBn2A3ZrUu+/ 7vFjYoXamD/+tv7+WTaM8oSyFyKqtmP0IX891TD9eyrD X-Google-Smtp-Source: AGHT+IFhdCLWVEM57HRqk6OabF6FrJebwuAosJRQG5OJxOeSaBEuUkYli0lm+I2KZQt0v9rfz/WN+w== X-Received: by 2002:a05:6a20:159:b0:13e:82ae:483 with SMTP id 25-20020a056a20015900b0013e82ae0483mr10127578pzs.31.1691461723315; Mon, 07 Aug 2023 19:28:43 -0700 (PDT) Received: from [127.0.0.1] ([47.75.78.161]) by smtp.googlemail.com with ESMTPSA id c15-20020aa7880f000000b00663b712bfbdsm6864298pfo.57.2023.08.07.19.28.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Aug 2023 19:28:43 -0700 (PDT) Message-ID: <79508337-08c1-7926-afd9-af21ee128949@smartx.com> Date: Tue, 8 Aug 2023 10:28:36 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/4] mm/hugetlb: fix the inconsistency of /proc/sys/vm/nr_huge_pages To: David Hildenbrand , mike.kravetz@oracle.com, muchun.song@linux.dev, corbet@lwn.net, akpm@linux-foundation.org, n-horiguchi@ah.jp.nec.com, osalvador@suse.de Cc: linux-mm@kvack.org References: <20230806074853.317203-1-xueshi.hu@smartx.com> <20230806074853.317203-2-xueshi.hu@smartx.com> <5c9ebf69-cd59-0fb3-bb85-1ab219426530@redhat.com> Content-Language: en-US From: Xueshi Hu In-Reply-To: <5c9ebf69-cd59-0fb3-bb85-1ab219426530@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: C4E7E12000E X-Stat-Signature: yugdzeqos6i5zfi7dxhd495hmuubiuxk X-Rspam-User: X-HE-Tag: 1691461724-827657 X-HE-Meta: U2FsdGVkX1+/POP6aBWDXQCyMj0tZcX566I0NUCjNVipa8e8tdtZXDzyWeDmKEmp2glhC+Ekup75bl3SIO6aWn8knLuHzpukvRY0DW1tcpTb8dqcKxA4Nsdsz0mC2m93mgPzjS/vcu2uZ1W8GGJQMx5ltp6fEMkIIfbgl5Ku100BnETWmdkM+WJ0wyvgTRrH+SXXh1OHS9izT4kTWu2KZvR59Wp9628FybDjrc0YzwCMCJnMjnqTzBoiaZWszw9ovLPqTxl850GwGovMktTLiBudC4WrB2blSsaBQWjejieP13zdj+iteKwuDYZzM5g7lyOxs6n8jqgx1vpfP241qMNEKPuQXM5Ws4kzqwYDtwvP2pwAnf+1S+9W2eKn24e+36P/NOW/QBZgivssobtA5TjFrU2knk9LdLRvqNpVrnCEOCU0bI1/7aZ/H9re0sqLJ2qO3o1VGZCTPNtfgKh6A6qn36qHrno9ZpCB6x+yYeb/2MbmBL/JfiwSG5qgZVAGJnv0D0QTMH05vjnmii4i3v97RNHaGQ4zAobzG99yDQVcyvHoQM5a/PmCi4KZnqqZdOxweXp+9DD0XWPdLNkNxbyM3Yue4htw154SwE1c5vVMf369Mm2Lw/0/cxva4lKalyIlc8qZZaAMKoGG7gAvtheU/IWkFDYKeaAuDd5tENzbmYy+B7lXEpVJ8XPe4KwqywIny+dsLs8hmieZENnJLvf9SCrsTfGJansQh7u/TrqGKWToT2Fj7AcWQplrirgbXN2+oozopY30RPXMb90tmCOLsuiKL+6VZGNzpJG+8oIc4bVsU/zhuHxxFdz37kMQwKVQvy4z/NKvV4Wx/Qf3j65uT03wXPIzbKly7Jv/EZh6E81x1R6+qiQx7nNBqQ7UmuqPlkeA0UUVuJFBqv9PDWMgzedxzYsqPSKjIw8edtTnzqKau8p33kvNQxXHXJoZdEOWrvdV0Bm/HKChpd7 BhzX1NET UjY4V5wdUd4C0TPghBwkxO/dKB+VfkUCQDfAtyvF9Beqe8KkGhtRrv2Z/gCji1fTvKT1Umb2OvJfNmbKVYPDr6LRXXQTD07HXl7RrRM+bhoMPXBH/3bcVgk9hCrGV9MAytM+LuJ6DoREll2WCcjj03SqJ6xmf9Y2Etx5E6na9VYTDz/TJU+W0XIN3kF28bq1u52EF7BjYRyvvykcvbqKFrLgMXsfow1liREb426I7TV5BuqV57JVfzmIKndVNYD24LJBKtoEjfdUG0FmUY13zoThc2I4U8AUCGpbyzpO/5lh64azv+/Dpirpz9PPWv6eXzCWTd1YD5mmRwkap/U3MaZuisTABzHibp/xwKZ7K/Q/UYyZPhZcQuHewxk6TYlYvgAwkrpPZTaoaSWCuN6SGOAuSmY1RolHD7pFNZ6hzw9G7UnsNEl6rrY2BN7fp4I3d4WXDm5xFJttLWWGEZXmRkBLVXQ== 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 8/7/23 23:15, David Hildenbrand wrote: > On 06.08.23 09:48, Xueshi Hu wrote: >> There are currently three 'nr_hugepages' used to export the number of >> huge >> pages: >> 1. /proc/sys/vm/nr_hugepages >> 2. /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages >> 3. /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages >> >> For consistency, all three 'nr_hugepages' should return the total number >> of huge pages. When written, the number of persistent huge pages will be >> adjusted to the specified value. >> >> But, /proc/sys/vm/nr_hugepages returns the number of persistent huge >> pages. >> > > But that's documented behavior, no? > > Documentation/admin-guide/mm/hugetlbpage.rst > > ``/proc/sys/vm/nr_hugepages`` indicates the current number of > "persistent" huge > pages in the kernel's huge page pool. "Persistent" huge pages will be > returned to the huge page pool when freed by a task. A user with root > privileges can dynamically allocate more or free some persistent huge pages > by increasing or decreasing the value of ``nr_hugepages``. > Actually, Documentation/admin-guide/mm/hugetlbpage.rst is contradictory about the definition of /proc/sys/vm/nr_hugepages. The documentation says: - ``/proc/sys/vm/nr_hugepages`` indicates the current number of "persistent" huge. But, the documentation also says: - The ``/proc`` interfaces discussed above have been retained for backwards compatibility. - The ``nr_hugepages`` attribute returns the total number of huge pages on the specified node. When this attribute is written, the number of persistent huge pages on the parent node will be adjusted to the specified value, if sufficient resources exist, regardless of the task's mempolicy or cpuset constraints. So, I create the patch 4 to make the documentation more clear. If such subtle inconsistencies result in unexpected behavior, it can be challenging for a system administrator to detect. Thanks, Hu