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 69076C001DE for ; Tue, 8 Aug 2023 07:58:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E3A9F6B0071; Tue, 8 Aug 2023 03:58:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DEC0A6B0074; Tue, 8 Aug 2023 03:58:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C8B6A8D0001; Tue, 8 Aug 2023 03:58:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B932B6B0071 for ; Tue, 8 Aug 2023 03:58:39 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 7749980ABD for ; Tue, 8 Aug 2023 07:58:39 +0000 (UTC) X-FDA: 81100185558.29.5717BDC Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf25.hostedemail.com (Postfix) with ESMTP id 25E83A0010 for ; Tue, 8 Aug 2023 07:58:36 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=V8iQV9Pi; spf=pass (imf25.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691481517; 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=tyaAtbepXoKdtpYiSNnD5N+UX19Z7wO3OUlyn+RruJo=; b=WaDlK2jSwgC8caObkS11q2UxKbehLK1vvSc5oe+wSEJW89xrPjtAD75clijvPvLAGKyaIr xKTkAh2Lfav8YTaNPF7txoo6R4p3JYaLD4yx2B/Z9FuJy85lypVrBT1LKcLxVb+5DeUQdH 3BZw5/Ck4FVRroR+iyzVQEchpsW7W+w= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691481517; a=rsa-sha256; cv=none; b=2vtFilXinzZzT/OiZePmbJtEGOUlJW2Hgi65nyx5DTLLyohsu36jRyjZ6IBB3rna2jFNI6 mA3iJcQ4lSUL6Q7G69jkelhYR/HvZNKaEOTGKkS9QeqkSZ6wHot7KTzOv2QEU41WpZ4LIc 4IJy9Nj0pVIvq/S8KANswwplc5VE3j4= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=V8iQV9Pi; spf=pass (imf25.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1691481516; h=from:from: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; bh=tyaAtbepXoKdtpYiSNnD5N+UX19Z7wO3OUlyn+RruJo=; b=V8iQV9PiiHjSsDeSlTOOK8W9mRpHOmI0fkELAXXVakqeCbgJp7WvkY3UTA0wgxkjudEs6p fBXHJVkiTPRY69Mhz6x/NQjjxkBvXxGq5SCkwr5CEhJcLeWvfWoqNRUUvJRE9TmSxYPNT0 P8f2RhYZDOc9+k1BdYKNgU2wmDEU8SM= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-209-4tDeSRsBPKCsAF5z8pI5Xg-1; Tue, 08 Aug 2023 03:58:35 -0400 X-MC-Unique: 4tDeSRsBPKCsAF5z8pI5Xg-1 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-3fe2477947eso30945535e9.0 for ; Tue, 08 Aug 2023 00:58:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691481514; x=1692086314; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tyaAtbepXoKdtpYiSNnD5N+UX19Z7wO3OUlyn+RruJo=; b=k8e+062Twm/W7lP1jga4BlwpnBY1LhJlixWG88qgoStklyZja3mOvZJu2Lbb/sVwy5 y2bbk1ye6ZLhr4Tu4/qvQ/E1xhMtxKYMXWO1O7zgryC0fiOfC+wFuI/RCPrAjJku/zBt WbIreynqNyQTVKyLZO836ghc/Ie21FCaStfTCJiiFmOBUb4wDOK30ihSbeT4d3miODVA joAxQYSk4dJP+Za6KITbwwffTcsjU6FpkRijm2ASUkjX5Phl7gxpuA28PW7Ebl0mwlrt mpKpt8FhQc8WAuad3iIZdiFcCGIuWsn9ZXv8DCLXLaiBX4P7CATXIzejJiqf3OHnpbIb TVng== X-Gm-Message-State: AOJu0YyhAu16dlOLQ3ykRF5PSrQHuXDXzINFaVE1XaSG3UmSPUsWRCT7 VGGiwSVmiiI95NpWa7gD2JfAYg+MdUF4cy6UP7zb0ttPWOgqXce7/owfJdxUxPR/Z0wm896uTw0 d3SfsBxOLjjM= X-Received: by 2002:a1c:7211:0:b0:3fe:19cf:93c9 with SMTP id n17-20020a1c7211000000b003fe19cf93c9mr7744805wmc.1.1691481513936; Tue, 08 Aug 2023 00:58:33 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEkA9dGpZHsA7/Sh/EJcDeKz0NTfS0LiJ4CLWzNeNSHOgRt8VPf/33gTF49ydBPBX16RLzm6g== X-Received: by 2002:a1c:7211:0:b0:3fe:19cf:93c9 with SMTP id n17-20020a1c7211000000b003fe19cf93c9mr7744788wmc.1.1691481513571; Tue, 08 Aug 2023 00:58:33 -0700 (PDT) Received: from ?IPV6:2003:cb:c74c:4500:a7dd:abc0:e4c2:4b31? (p200300cbc74c4500a7ddabc0e4c24b31.dip0.t-ipconnect.de. [2003:cb:c74c:4500:a7dd:abc0:e4c2:4b31]) by smtp.gmail.com with ESMTPSA id f20-20020a1c6a14000000b003fe24da493dsm12942218wmc.41.2023.08.08.00.58.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Aug 2023 00:58:33 -0700 (PDT) Message-ID: <5b404d86-6b6f-b6c7-6286-f2ce3c4b5424@redhat.com> Date: Tue, 8 Aug 2023 09:58:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 To: Xueshi Hu , 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> <79508337-08c1-7926-afd9-af21ee128949@smartx.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v2 1/4] mm/hugetlb: fix the inconsistency of /proc/sys/vm/nr_huge_pages In-Reply-To: <79508337-08c1-7926-afd9-af21ee128949@smartx.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 25E83A0010 X-Rspam-User: X-Stat-Signature: npq1p5b3iz5eg7h135wmjdwowehbgo35 X-Rspamd-Server: rspam03 X-HE-Tag: 1691481516-166682 X-HE-Meta: U2FsdGVkX1+4eDDvLfzJIM9DMAgLrMmLgcuOhLJB7ZCIegF3eMwSUMDAkUrjbLyXkvQfvh/4NOT1aMbiZuCrIo0EijyWd9pm5k5NTf/VBo9BTVGzEZFW3dHSVDLDlONs30BFfqFZJ18/q/uqwHGGeilkFsbObi82Oozx6SoY7InrT/ppoIKusMtFwazI9z+G1FOOMxp/lkUzzO7PXRSQMAEZo9mL4bZD/uBStmDGWeeNVv9nrye75oDHwf4xoawxGqCmRP2/ARoPXoFvRNlMhCJI+m7oDq6QWoj95REChoLuf/Cj9UE3TinWOP0XAvKqQslnQLJ5gIdKJFk9887GV0qjPMciDmSD9aaxMXdi5X//ui1ZiWJMOrUSBLmn40eI2UzXLAZwefNqvXlLAPVknGAD8BTT+SFTxfwHCaM86ymqxHGiY3yT1pK3LE28e5KwO6O8KWqyq2eivuhq5WNp9AhAG8hd7dLZZEVuv7i6H5ZhIkxR+U7Aa3pOF6F3KmLAYS3B+exeIigZIHlId4fpMnybSfFAIAmzVTDgj++FdAzrcYe2WqzzKVpCdis65ppwo1gujDUXS0Ndsfh95vHzWEgD0sxy2Lo74bFAFrcjYXVSJ5mRlqeH1BOc7pZeOjBvcXjOG+3WGc0weHGXji9G84mRMcNxILZsBSgTTmW/UdMptOc43J3AFuytLax2w0IHrlysgTpVhwWk8bk8Vai8T8wSEAlIomhQKjM4DpXdeub/JuFLA46YGmVxVe02bx4QSnYR6KS12g203nZHmFwzTBFWoWxGstfJJHH9RAgCnJb0nrXlwYVptPziBy8VakpCkiTgW07QffIaZ6GkYmY5vWHgpYNIWIB+L5HZWEt3G4hRFYSNOTrkO5tkcpPNgZtxR3593ias1lFa/7kL0WoFuAka2+f8i8GvlUDDdsZZ+9i5Xqtty2W81q/zbUN4T7Alo9EzjSAXInUQa7O0iOn BSvbE92Z dGXcl7ZfUyOhqwqAXDPISSG/vIWIizKzYYU1lYxiiwCYBkNP1p5OM8R/nffrhYB13+mduMy9JtAvNAff5EN1LhWF/DufuUQnJ3fSUPsJscRHdCTkYsYBHfsSFdRid+hAvlYz2nyv5XCYoLuD1nKI1QHHf+Aeh1erGskTMGF4QP99GD2dSTAmDawCs3tAnJVZpkjxdF2ueBS6ZXDRTrgsF5C0XzDqGYGe/SfklnuHT39UXKnjFdhdZx8H+zHkichUeNEIJApc0xqwoF0ypV0rNe1sYbj/nArSk1HRbXDn1tfKX3GpVTaIfUH/uo4ijbnvzhG1gFw4z5R21qDae18TLeebuILQ65Y68d2EVMdNE7KaeIskPmVpEHbZKkLdxf1orytQuLFKp8iXwD/uCbuiWv6UFAtPIsWMxdK+4UVg62/HZnhhjK1k+cuvJmEcH9HwBVBhzHTHR6C651yg= 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.08.23 04:28, Xueshi Hu wrote: > 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. Yes. And why shouldn't the behavior of these toggles be 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. That is part of the "/sys/devices/system/node/node[0-9]*/hugepages/" docuemntation, not "/proc/sys/vm/nr_hugepages" documentation. It's in the "Per Node Hugepages Attributes" section. If I am not wrong, that documentation -- including the usage of the "persistent" term -- were introduced in 2009 already: commit 267b4c281b4a43c8f3d965c791d3a7fd62448733 Author: Lee Schermerhorn Date: Mon Dec 14 17:58:30 2009 -0800 hugetlb: update hugetlb documentation for NUMA controls Update the kernel huge tlb documentation to describe the numa memory policy based huge page management. Additionaly, the patch includes a fair amount of rework to improve consistency, eliminate duplication and set the context for documenting the memory policy interaction. So this has been documented behavior for a long time. > > 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. Your patch is changing the traditional, documented behavior to then change the documentation to match the new implementation. How can you be sure nobody relies on exactly that traditional, well documented behavior? Why change the behavior of an interface that is kept for backwards compatibility, that might still be in use under the assumptions that the behavior is exactly like that (and for at least the last 14 years)? -- Cheers, David / dhildenb