From: Mike Kravetz <mike.kravetz@oracle.com>
To: David Hildenbrand <david@redhat.com>
Cc: Xueshi Hu <xueshi.hu@smartx.com>,
muchun.song@linux.dev, corbet@lwn.net, akpm@linux-foundation.org,
n-horiguchi@ah.jp.nec.com, osalvador@suse.de, linux-mm@kvack.org
Subject: Re: [PATCH v2 1/4] mm/hugetlb: fix the inconsistency of /proc/sys/vm/nr_huge_pages
Date: Thu, 10 Aug 2023 15:15:53 -0700 [thread overview]
Message-ID: <20230810221553.GD4734@monkey> (raw)
In-Reply-To: <396edcf4-2b43-ef2e-baa3-b732134b8f93@redhat.com>
On 08/10/23 09: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:
> >
> > 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.
>
I am not sure if this was the 'design'. The commit to add the sysfs interfaces
is a3437870160c from 2008. There is no mention of changing the meaning of
nr_hugepages when read/displayed.
It matters not if this was by design. It has been this way for 15 years and
has become the expected behavior.
> >
> > 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.
Now, I tend to agree that not modifying /proc/sys/vm/nr_hugepages may be
the right thing to do. I 'know' of a DB that makes extensive use of this
and the corresponding sysctl interface. A pr_warn_once() may help, but I
still see the warning "Using mlock ulimits for SHM_HUGETLB is obsolete"
in system logs. :(
> Your call. :)
I REALLY would like it if all these interfaces were consistent and showed the
same information. However, this inconsistency has been there for 15+ years.
And, I know of users making extensive use of /proc/sys/vm/nr_hugepages.
Hu, did you get a report of this inconsistency from a customer/end user?
Or, is this something you and other developers noticed?
--
Mike Kravetz
next prev parent reply other threads:[~2023-08-10 22:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-06 7:48 [PATCH v2 0/4] mm/hugetlb: fix /sys and /proc fs dealing with persistent hugepages Xueshi Hu
2023-08-06 7:48 ` [PATCH v2 1/4] mm/hugetlb: fix the inconsistency of /proc/sys/vm/nr_huge_pages Xueshi Hu
2023-08-07 15:15 ` David Hildenbrand
2023-08-08 2:28 ` Xueshi Hu
2023-08-08 7:58 ` David Hildenbrand
2023-08-08 9:13 ` Xueshi Hu
2023-08-10 0:17 ` Mike Kravetz
2023-08-10 7:34 ` David Hildenbrand
2023-08-10 22:15 ` Mike Kravetz [this message]
2023-08-25 4:02 ` Xueshi Hu
2023-08-25 21:15 ` Mike Kravetz
2023-08-26 2:51 ` Xueshi Hu
2023-08-06 7:48 ` [PATCH v2 2/4] mm/hugeltb: clean up hstate::max_huge_pages Xueshi Hu
2023-08-07 15:17 ` David Hildenbrand
2023-08-06 7:48 ` [PATCH v2 3/4] mm/hugeltb: fix nodes huge page allocation when there are surplus pages Xueshi Hu
2023-08-06 7:48 ` [PATCH v2 4/4] docs: hugetlbpage.rst: make the meaning of persistent hugetlb pages clear Xueshi Hu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230810221553.GD4734@monkey \
--to=mike.kravetz@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=david@redhat.com \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=osalvador@suse.de \
--cc=xueshi.hu@smartx.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox