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 9C2E0C83F11 for ; Sat, 26 Aug 2023 02:51:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 29C27680010; Fri, 25 Aug 2023 22:51:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 249CA68000D; Fri, 25 Aug 2023 22:51:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 11279680010; Fri, 25 Aug 2023 22:51:49 -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 F20B468000D for ; Fri, 25 Aug 2023 22:51:48 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C9CD4B28AB for ; Sat, 26 Aug 2023 02:51:48 +0000 (UTC) X-FDA: 81164730696.13.337D4BA Received: from mail-qk1-f194.google.com (mail-qk1-f194.google.com [209.85.222.194]) by imf13.hostedemail.com (Postfix) with ESMTP id E5BF020014 for ; Sat, 26 Aug 2023 02:51:45 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=smartx-com.20221208.gappssmtp.com header.s=20221208 header.b=QKKAKVnP; spf=none (imf13.hostedemail.com: domain of xueshi.hu@smartx.com has no SPF policy when checking 209.85.222.194) smtp.mailfrom=xueshi.hu@smartx.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693018307; a=rsa-sha256; cv=none; b=DEy+Qr9Ej3uZZ/1V3gGmBH9Bm0r0WdnqKOjru8u6/9CybfZ/hvoTei3SDl9VYdMON00QvO udhm/2KUJTn95cewNI5dCd3RZ/PsoHJpngsFtn1D8qu4Ytgs7cfYTQ1Nl38Iftinw2sAzb qJjR4Y/Nf3kESOwN+GLU+b2apGfVepY= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=smartx-com.20221208.gappssmtp.com header.s=20221208 header.b=QKKAKVnP; spf=none (imf13.hostedemail.com: domain of xueshi.hu@smartx.com has no SPF policy when checking 209.85.222.194) 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=1693018307; 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=rngHJ2QgUh3OAv5CODwzVufhWFtLrBYEYSGDZxGdrZo=; b=aY7lIVGOfD6edv+8OZ6kkl67r28rr5ApTU0Ih9EqxA0QsUi5TtE+mkGkPlHLI/q+lFzEwJ cOXjyW0OjQmI+9pViJ+enO+CuDdfi7/zY2WwpwBIzGfs3HE9NuX/tCR7rnYI2Sh6wWZ35o w/tHp4vEfxXVw7X8GNpg7KzEDPAZWPo= Received: by mail-qk1-f194.google.com with SMTP id af79cd13be357-76da121478dso86527585a.2 for ; Fri, 25 Aug 2023 19:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartx-com.20221208.gappssmtp.com; s=20221208; t=1693018303; x=1693623103; 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=rngHJ2QgUh3OAv5CODwzVufhWFtLrBYEYSGDZxGdrZo=; b=QKKAKVnP5gESGtkUpSOmGGTOc0Avjk/3FRQzyrfReyosDLMBpRN0rVknST9itAubW+ /RprYIs+CL2dHkHNUWoPb7RgOeCwBhLp85k/qjgBadObfmvnGLUQW43ejhHaSBa8HOaq Dv3t9QBrqtGrQDMMVXfgBZne65vasZrYqp2cHksrJgOKYxCiVv5FUTnIcaabwFOuud9W BqqRq7ki2s0QiGEJOlyXnYWKvISXr//wh+Yqp/RJCX5/sgbk1o6LbQxhgko2PXP9SG2C eKbd3emLw0b2XQCbcHAYgjFWmGA1sO5/S9zCJdeysDUTR/ZvrsIISb92rmV+ls/dKrB7 Cx4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693018303; x=1693623103; 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=rngHJ2QgUh3OAv5CODwzVufhWFtLrBYEYSGDZxGdrZo=; b=a7CPd3Ccs4hVP+oynleOQkGcwCuUXqYUKyedqj7G9R6cjZkKqCXXU0Myp10T575plC jq2JDHRLhp3cfI3cL/YYd8Os24Yx7p96FaEgdulDxXr7ACZPxLboy8cGQVsHJ0KYA1Rv Q3ZOBrr62NRUoXHfQiLCwImKmu/WpLLXuSGvm2lDL/8HMep2qhDustCzJJ+BmLYOGHPn Qde8HC0PCJc0wVezVhcDP+FoHQP/Jzg7X9FKCSXTvDzt783DDCyFugs6dOR2pcONrLAb bdCGxMg5Ig4jZu2d5fVkUmXKPtfqwqDJ9VYfGH5vY29iaW6Nff3gLSfVSAFgJriNaiKF yxkQ== X-Gm-Message-State: AOJu0YxvVRrrylKO+zMOFQcxaS8/GRkMDVgOPA4PfnNaBpsq5KDQ0gv7 Mh+flmsNdXUqLPRfychAQOxlaQ== X-Google-Smtp-Source: AGHT+IENwQ1aUF+qQUF8zqCgfC3fUFdGUeroGJ5g984IriS5VoowYBErC/IrizI12fmJW3kiS2Ad5A== X-Received: by 2002:a05:620a:66e:b0:76d:9ffb:3a8a with SMTP id a14-20020a05620a066e00b0076d9ffb3a8amr16091218qkh.76.1693018303123; Fri, 25 Aug 2023 19:51:43 -0700 (PDT) Received: from [127.0.0.1] ([8.210.91.195]) by smtp.googlemail.com with ESMTPSA id iq1-20020a17090afb4100b002692e06bc36sm4203624pjb.30.2023.08.25.19.51.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Aug 2023 19:51:42 -0700 (PDT) Message-ID: <2e0dc53b-ebe3-3424-bfab-b56f32e27ca5@smartx.com> Date: Sat, 26 Aug 2023 10:51:38 +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: Mike Kravetz Cc: David Hildenbrand , 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> <77540220-e1ca-a87f-51ce-905782c5ac91@smartx.com> <20230825211519.GA3730@monkey> From: Xueshi Hu In-Reply-To: <20230825211519.GA3730@monkey> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: E5BF020014 X-Stat-Signature: krtquxp8cqkeftr6hpb18a3ubfen34qt X-Rspam-User: X-HE-Tag: 1693018305-214246 X-HE-Meta: U2FsdGVkX184cfgN/5LYb24mxxmIQU+NkFj0e08VfZRvTTAwdvxkzP823NvE9OSTqINADeCL36/svMg5vP6E5K9zTMeMpvImBkwuuqRReiP356/7hFm/4R+gJY8tQvEEMCN6IwyvG4BU8UYKfQHdVSkqKCYHb2TpMcB/9snV9ZDiN7c42dhO4ICZgmXl1DNDa7kidwiDwFiI/D6wWvjUkVuq34lJYHyca9lDWM8qeqJUSKPd0DHCl23ZaSjmssCaAxen3sDIDFaVufgQmQfnh5wWgrKAWkdFLxF7zufqtYOCf8dt9H1Gu3h2QVDMWGbG5CNh9r2V8uaL4DYibZNaue4TsRrXJoNDgp0rysc5PZWEsDBL4s26n9FO4QxB7Zk37KKYVh/SLOjWz1bxjgMN2Klv0BsKxIAkCjHKa1KGAL005jKOXiORtmiq53mj9W2OWXdWtvUncW6xb0+AIZVI2U9J4qsVntUZEYD0L8q8m7SZ0EoDipNLRK7RHnror0hbcxsT8sDNGkUHc4k8R74ZbA3IBFiIW8p30BB9JRAaesr1D0H3rSv3DDXykVfZXCeEq11z6M4fcz+2p4fPimNcX8gRj0BOwocK3yvzCLTfe6Es17EWxYMfHsg27RSmdfqc/yNL0wDfwzjSRXeEVo4YEFQw181z270Pk4xS0J474Fte4sq1Fqb9T051uhJJMRbgYStoz7SiXVYwNhtiQj4O9uBg2LTX0FeXLRE5gzPBKkWOciBPJ0KUKL3N9cumkYSIfQU+Uuj9lG+VqQk+rKNSgEFxJ2d+itzZd6j25GFu5i9l4bZZcGKfGvjxGLS2/n8fuuodUyWVV8uEJDce0vuQQhJIc7+JqgSBE9GW5V70Wq+qNw+bChkVaOS6wbHvNlVhGFTz+7f+9DbD9KxoPs6wcCf6ARDRPsx1vy7CkfElDJEsPCKKjIHlPS2/nl0tKap2HStQBht1TuiLOHnr3Br 48VwxDxm AEN+in9yPeQsMjWrDXjcM8abOswlLLN1dIPRzNdNOWKC9klw3WD5+e3ZGiq95m4FHHWm6b9bz9nEaekMdQt/BGN26Bxqyys+oTNnRj2owSo5jAeqyQgoSBbI1bM4K/BdIWmbSUl7s2rAaO5kOgZoPwn0C+jDp9L85rCPM8KKnu6Z1dIEBXbCCxLcroA9PMZVH0+zpyY0S9qGrOie57XlC6vAX7U1YlWAbZ1tT8BXEr2vt5onynyP1LH9yLfBWKTftqYRGsPxEIJhuvxSHZOL6TVPHSXjfs7VI+ObECzyVljNiyZErN7BKXONdNrRPfzpSAFyAbwF7LfBNiFHVNo2HJsmKOBx4e7MSD8ajeRiWsqJ1Td4BTbzwrCx5XpRjvjhnABTCsOJHyNUkqIiGGAZtMEJyZxUEGhzWZGgo414ianR9bxhTclTR1lDtmJwLjo3+mFZblx3qlJ2MB9MFn+dXQ/KVOi+qg65EWvDHvUrHgDOXc/OzgwpkKikgrqGVMdrlAV8jpJuu29ZSQLo= 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/26/23 05:15, Mike Kravetz wrote: > On 08/25/23 12:02, Xueshi Hu wrote: >> 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 for your patient reply. > > I believe just updating the docs with clarification may be the best approach. > We need to say that /proc/sys/vm/nr_hugepages and sysctl (vm.nr_hugepages) > display the number of persistent hugetlb pages in the default pool. And, we > should probably define 'persistent' as well. > > With that, this patch should be dropped. Without patch 1, patch 2 is not > necessary. However, some cleanup (possible elimination) of max_huge_pages > could be done in the future. A modified version will sent later. > > Patch 3 is documentation updates which we agree need to be performed. I can > assist here if you would like. I would greatly appreciate your assistance. > > Patch 4 is most critical as it is a bug fix. Perhaps this can/should be sent > separately. Ok, I'll send it separately. Thanks, Hu