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 CA3B2C3DA6F for ; Fri, 25 Aug 2023 04:02:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3CDCA280074; Fri, 25 Aug 2023 00:02:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 37DDE8E0011; Fri, 25 Aug 2023 00:02:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 245DA280074; Fri, 25 Aug 2023 00:02:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 12C738E0011 for ; Fri, 25 Aug 2023 00:02:30 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id E06D51605B5 for ; Fri, 25 Aug 2023 04:02:29 +0000 (UTC) X-FDA: 81161280018.02.25198F6 Received: from mail-pg1-f194.google.com (mail-pg1-f194.google.com [209.85.215.194]) by imf04.hostedemail.com (Postfix) with ESMTP id 07F364001E for ; Fri, 25 Aug 2023 04:02:26 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=smartx-com.20221208.gappssmtp.com header.s=20221208 header.b=LvNtUEF4; dmarc=none; spf=none (imf04.hostedemail.com: domain of xueshi.hu@smartx.com has no SPF policy when checking 209.85.215.194) smtp.mailfrom=xueshi.hu@smartx.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692936147; 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=o8cbWWyACItbpqR60efq5Q5Wv76RapvE0ecWL5ewvc4=; b=Ml9+ycZ0R7FpZyzpFqOaJldL6+twqzREbuGoiqsykbjuudvqQhWqjoXjGeet9CPKq0Avk9 3BDhLqrM7VraQ0rhw7SQY7IajkBgJ1Z0t40Uq2lYgGS6gqFoHpYOvdraJCP/KbHkMoiEKe NjM9SdlrAescgdC+vVCHc5myKWgNnEw= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=smartx-com.20221208.gappssmtp.com header.s=20221208 header.b=LvNtUEF4; dmarc=none; spf=none (imf04.hostedemail.com: domain of xueshi.hu@smartx.com has no SPF policy when checking 209.85.215.194) smtp.mailfrom=xueshi.hu@smartx.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692936147; a=rsa-sha256; cv=none; b=MozmsynPUgR1GPYw5gdaWQANZZ+I6s0hzmQBku2Dk1ti8T1zdbTm/yzHawO8ouDSEQgzV4 LCNVaaEQY16filJ+XyWG+KDOMyQJJjZGOXEUSoLsCW7nma42E97k99kwcEtJddJLDQk8Za z5dgK24W8nBQInInuZH0yN2QtKmkIlo= Received: by mail-pg1-f194.google.com with SMTP id 41be03b00d2f7-53fa455cd94so263182a12.2 for ; Thu, 24 Aug 2023 21:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartx-com.20221208.gappssmtp.com; s=20221208; t=1692936145; x=1693540945; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=o8cbWWyACItbpqR60efq5Q5Wv76RapvE0ecWL5ewvc4=; b=LvNtUEF4Np6g/HsCytEKtyQAY1PkR4BKspujb8YLsDVOX6cQ9J2e3oEByDvkt1pdQ6 b1r/Nh7DBNcSlyjD7DnTWul9TSS89upFimMSlUH79apliZBZpLBEhUgk7eSAC8Cx4qpc IBZYDXXnBxhZ/IpbiJSRRmbT3dnVg+gF/CWS/sFm09fwiuwDMyV7R8AYdB2j7zHkOX0L Z34TyG7k/OYy+yf7bf7BRz+b6N1M4GSA/r9SLpcB6+JYTHP0Qj6gj+PR+KfU57SNnUY7 gZuVEEG6lH+02k+dfyxz316jUFswPXH6FFhjljny26ZPLdlwUQWYV+Zcz+O4PKVrI9TB k0lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692936145; x=1693540945; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=o8cbWWyACItbpqR60efq5Q5Wv76RapvE0ecWL5ewvc4=; b=f+qHHFpJ4xtsHvwJPKYNB22WhMbxiWLffWhXl+qx2oLCgHMZMlXyBMjHaxrgjg7jF7 NvPqkbutNTPiNzEOV2oNymMc/f+mGr1dSvMRXxYrISKxM5tfZVRoY2kr+T+kJJDBZwZf lx8FWERK+SMW3LCFlytz4qzN6TrwHcodOuQch4dFqafO+kU9FnwJG+7MF+OYcqs3Jo3k yveKne7jOJ1lcDEdfHs0iLfcOhxUtBnbH3jb8th/vJODhLZgn6He2DYW09AJ68+XnuJT oVQBtT6wt9XukLjMVTgln+qNSz0gxXoeOMcsu76eOwpHIE0SWJvopuva7O+kmnm22OKw xbDg== X-Gm-Message-State: AOJu0Yz8i+lceZlnpSGiKjHA83zCSRjmjis8QcQwBalblC0da+oilc5L MSSKEehji8Xx70I6nFJpbHNIFA== X-Google-Smtp-Source: AGHT+IEJuewQiP4LuHTlF8bJyi2OpqMw4xgOyqvP7ZQ75tcn89Y36uXYTex/DGOM4Pd5PSsAsYzPeQ== X-Received: by 2002:a17:90a:df0e:b0:26d:d2d:1a90 with SMTP id gp14-20020a17090adf0e00b0026d0d2d1a90mr14196674pjb.1.1692936145243; Thu, 24 Aug 2023 21:02:25 -0700 (PDT) Received: from [127.0.0.1] ([8.210.91.195]) by smtp.googlemail.com with ESMTPSA id i17-20020a17090acf9100b00264044cca0fsm3901592pju.1.2023.08.24.21.02.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Aug 2023 21:02:24 -0700 (PDT) Message-ID: <77540220-e1ca-a87f-51ce-905782c5ac91@smartx.com> Date: Fri, 25 Aug 2023 12:02:20 +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 Content-Language: en-US To: David Hildenbrand , Mike Kravetz Cc: muchun.song@linux.dev, corbet@lwn.net, akpm@linux-foundation.org, n-horiguchi@ah.jp.nec.com, osalvador@suse.de, 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> <5b404d86-6b6f-b6c7-6286-f2ce3c4b5424@redhat.com> <42b78b9d-0a2f-c79d-0298-e4a7283a5633@smartx.com> <20230810001755.GC3537@monkey> <396edcf4-2b43-ef2e-baa3-b732134b8f93@redhat.com> From: Xueshi Hu In-Reply-To: <396edcf4-2b43-ef2e-baa3-b732134b8f93@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 07F364001E X-Stat-Signature: c85pphufmuzx151bpw8usrmmjucg8z64 X-Rspam-User: X-HE-Tag: 1692936146-745451 X-HE-Meta: U2FsdGVkX1+nxRq8jfk9+vVIt21Seh5U8gstOJCScz5oz/J8iy3sqftA7tzvHTCx9T1yXFmJM4b02VEagmQOLknpo/GsFB+kErGcoBa8N7U5xNj7gaZCKJosZDls+31p0UzafiO8zpTF136ovRjAi979j3DoVEveYLvzPhhk5mzecu/KDk4lI7BIRBuW6kB3Xq4lwXrjBW5KJ5cV3tQDLQpsqaLF2HdNQv2TDWeoGa8vloWq95Sn71I6dWT5loPwqCvYgrFytiDT+o6sX0UYOx66QMB33OpWhXrM4EJdUxvl4j6nqVrznxfKnFK75HBv2J2iHeyADnPVQJO2yCwOXb7C9oJOQzIRHlwgDxbmFUD1LYH/WR3TK6H2zLpta7rr3AfZClBB0Rwjq/6CxctN/Ubcd5xMKihA090rmkUo3kZIvHOi5EWM4B2Q4ZuW1R0HeGINOtwB7n7BbbM2SJOOG5T88IR/6eDu3Y9iurONUGc8mVOERInBCtqN46THwAQ7I/lXK537NoQO8802gGFUp+wlHmicOAxdxlCpHTXb4ejyN/bWhU67wrWd8AeqUHrAJkS16Ed6NPbHwxc8WylnWRUad3L3G+7D06p8MqfZ7c4HDlHuEQPTQ18COF2Qe9dByLtd26Qm/646eoJ/cjRQ61zsM6KjYrWxyM50UbEUcbfLYLfhbUrIO1ge0YiOn9Nxb3/lU5LUNmLqYaDT1glyUgs4aNjamyHzZvhIoPCp3UzjgpvpogYy/dpPwxspSPfTOfgwRLrpwddfdAdTp1ce+/1C8wf1J9c+3RyEMbuWzTGbLr1uc+qcGhePHM5gBxS6Ds43XyLjeVRhzypWza0VnXe7wdHp8D24AqZj87hG23p/JgfnRoIcCPJCN0EJDw9tL/DBWVrCUYBr8+e8DoKn3ep23DCPzPl4l66QyLeaa0KG/ngPMOhQ7ywsIPV8kBHc/vHQ0cLsa1BeqH4V2wE 1DScXgN6 szYQMnL3OkUKi+zVzQ9k1DEHizJbGWJ1D9IFGPGjt1WOB2IQXbJfFMw/O3lIZVF+KqcCzuBR9AdKg3J2FhaVmrugMfIoAfOkQTRt5pARzuB7HTuO8im5RYG+84pAdtJg6Y45WayZlJsDgAuJiAO43HO9EnY5R4uXunw0pyImsgp3LujTmR+fBIMkIXsqVoDVROXu31+QHwvxRK7T06OclvcWWaMoF46ZNx156Tq82Sx2+RCI9QD9CPmyrxkrG+BcDvV50HJoC2yiLru5zmjdHpM7Nzc/R0fBKdjmYALLJauC91IXkI7xrbhgBWPP/Sf0IGumgbSfPFWiO92rFDaX3Pbs/8mc8oPU9oZjUXTOSGbBIT/KefH7ZaXIoQDu2tqG6gnMvHxFv5VcCjJc8dLmRM25MP3NkIUK5Lotuc+RhmChJXVTS1nQmcEuWN5u1u85rpDcaiyfIozzpuVyktf9arMlldB5YQAmmdZmxMiwRheCDu1nCYVxKNG8MOibp/3METfliiTBBNZGZuEo= 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/10/23 15:34, David Hildenbrand wrote: > On 10.08.23 02:17, Mike Kravetz wrote: >> On 08/08/23 17:13, Xueshi Hu wrote: >>> On 8/8/23 15:58, David Hildenbrand wrote: >>>> 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: >> >> Sorry for jumping in late, I was away for a while. >> >> Hu and myself discussed this previously in, >> https://lore.kernel.org/linux-mm/20230802182031.GA4762@monkey/T/#r1bdc8eeebafa08699fda5b15f247f3f966ddd090 >> >> The documentation around what is displayed with the hugetlb proc/sys >> interfaces is at best confusing and at worst wrong in places. >> >> One source of confusion is use of term 'persistent hugetlb pages'. The >> documentation does not define this term. However, there is this >> definition in the code: >> #define persistent_huge_pages(h) (h->nr_huge_pages - >> h->surplus_huge_pages) >> >> All of the write/update interfaces modify the number of persistent >> hugetlb >> pages as defined by the code (#define). Only one read/show interface >> displays the number of persistent hugetlb pages as defined by the code >> (#define). That is /proc/sys/vm/nr_hugepages (and sysctl). > > Yes. > >> >> When thinking about this more, I am 'guessing' that when the >> documentation was >> originally written the term 'persistent hugetlb pages' did not refer >> to the >> #define in the code. Rather, it was just the number of allocated >> hugetlb pages >> that 'persisted' until modified by the admin/user. >> >> There is little doubt the documentation could/should be updated. > > Absolutely. > >> >> The question is 'Should we change the /proc/sys/vm/nr_hugepages (and >> sysctl) >> interfaces to be consistent with all the other read/show interfaces? >> >> The argument for changing is that consistency is good. Why have one >> interface >> that is not like the others? >> >> The reason for not changing is that this is the oldest interface. The >> information/interfaces originally available in /proc were created in >> /sys. >> And, as mentioned in the documentation the /proc interfaces were kept >> for backward compatibility. Unfortunately, the meaning of nr_hugepages >> was changed the /sys interfaces were created. Sigh!!! > > Indeed, they were designed to be different and to just leave the /proc > interface alone. > >> >> In the thread mentioned above, I was in agreement with Hu about changing >> /proc/sys/vm/nr_hugepages to be consistent with other read/show >> interfaces. >> Now, I am not sure. > > My take would be to just leave /proc/sys/vm/nr_hugepages alone. Maybe > pr_warn_once() when the interface is used to guide people away from that > legacy interface + clarify the docs. > > Your call. :) > Considering /proc/sys/vm/nr_hugepages may be widely used, and it not total equivalent to the interfaces under /sys. What about just clarifying the docs? Thanks, Hu