From: Roman Gushchin <guro@fb.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, Michal Hocko <mhocko@suse.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Dave Hansen <dave.hansen@intel.com>,
David Rientjes <rientjes@google.com>,
kernel-team@fb.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm: show total hugetlb memory consumption in /proc/meminfo
Date: Tue, 21 Nov 2017 19:59:54 +0000 [thread overview]
Message-ID: <20171121195947.GA12709@castle> (raw)
In-Reply-To: <20171121111907.6952d50adcbe435b1b6b4576@linux-foundation.org>
On Tue, Nov 21, 2017 at 11:19:07AM -0800, Andrew Morton wrote:
> On Tue, 21 Nov 2017 15:15:55 +0000 Roman Gushchin <guro@fb.com> wrote:
>
> > > > +
> > > > + for_each_hstate(h) {
> > > > + unsigned long count = h->nr_huge_pages;
> > > > +
> > > > + total += (PAGE_SIZE << huge_page_order(h)) * count;
> > > > +
> > > > + if (h == &default_hstate)
> > >
> > > I'm not understanding this test. Are we assuming that default_hstate
> > > always refers to the highest-index hstate? If so why, and is that
> > > valid?
> >
> > As Mike and Michal pointed, default_hstate is defined as
> > #define default_hstate (hstates[default_hstate_idx]),
> > where default_hstate_idx can be altered by a boot argument.
> >
> > We're iterating over all states to calculate total and also
> > print some additional info for the default size. Having a single
> > loop guarantees consistency of these numbers.
> >
>
> OK, I misread the handling of `count' -> HugePages_Total.
>
> It seems unnecessarily obscure?
>
> for_each_hstate(h) {
> unsigned long count = h->nr_huge_pages;
>
> total += (PAGE_SIZE << huge_page_order(h)) * count;
>
> if (h == &default_hstate)
> seq_printf(m,
> "HugePages_Total: %5lu\n"
> "HugePages_Free: %5lu\n"
> "HugePages_Rsvd: %5lu\n"
> "HugePages_Surp: %5lu\n"
> "Hugepagesize: %8lu kB\n",
> count,
> h->free_huge_pages,
> h->resv_huge_pages,
> h->surplus_huge_pages,
> (PAGE_SIZE << huge_page_order(h)) / 1024);
> }
>
> seq_printf(m, "Hugetlb: %8lu kB\n", total / 1024);
>
>
> Why not
>
> seq_printf(m,
> "HugePages_Total: %5lu\n"
> "HugePages_Free: %5lu\n"
> "HugePages_Rsvd: %5lu\n"
> "HugePages_Surp: %5lu\n"
> "Hugepagesize: %8lu kB\n",
> h->nr_huge_pages,
> h->free_huge_pages,
> h->resv_huge_pages,
> h->surplus_huge_pages,
> 1UL << (huge_page_order(h) + PAGE_SHIFT - 10));
>
> for_each_hstate(h)
> total += (PAGE_SIZE << huge_page_order(h)) * h->nr_huge_pages;
> seq_printf(m, "Hugetlb: %8lu kB\n", total / 1024);
>
> ?
The idea was that the local variable guarantees the consistency
between Hugetlb and HugePages_Total numbers. Otherwise we have
to take hugetlb_lock.
What we can do, is to rename "count" into "nr_huge_pages", like:
for_each_hstate(h) {
unsigned long nr_huge_pages = h->nr_huge_pages;
total += (PAGE_SIZE << huge_page_order(h)) * nr_huge_pages;
if (h == &default_hstate)
seq_printf(m,
"HugePages_Total: %5lu\n"
"HugePages_Free: %5lu\n"
"HugePages_Rsvd: %5lu\n"
"HugePages_Surp: %5lu\n"
"Hugepagesize: %8lu kB\n",
nr_huge_pages,
h->free_huge_pages,
h->resv_huge_pages,
h->surplus_huge_pages,
(PAGE_SIZE << huge_page_order(h)) / 1024);
}
seq_printf(m, "Hugetlb: %8lu kB\n", total / 1024);
But maybe taking a lock is not a bad idea, because it will also
guarantee consistency between other numbers (like HugePages_Free) as well,
which is not true right now.
Thanks!
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Roman Gushchin <guro@fb.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: <linux-mm@kvack.org>, Michal Hocko <mhocko@suse.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Dave Hansen <dave.hansen@intel.com>,
David Rientjes <rientjes@google.com>, <kernel-team@fb.com>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] mm: show total hugetlb memory consumption in /proc/meminfo
Date: Tue, 21 Nov 2017 19:59:54 +0000 [thread overview]
Message-ID: <20171121195947.GA12709@castle> (raw)
In-Reply-To: <20171121111907.6952d50adcbe435b1b6b4576@linux-foundation.org>
On Tue, Nov 21, 2017 at 11:19:07AM -0800, Andrew Morton wrote:
> On Tue, 21 Nov 2017 15:15:55 +0000 Roman Gushchin <guro@fb.com> wrote:
>
> > > > +
> > > > + for_each_hstate(h) {
> > > > + unsigned long count = h->nr_huge_pages;
> > > > +
> > > > + total += (PAGE_SIZE << huge_page_order(h)) * count;
> > > > +
> > > > + if (h == &default_hstate)
> > >
> > > I'm not understanding this test. Are we assuming that default_hstate
> > > always refers to the highest-index hstate? If so why, and is that
> > > valid?
> >
> > As Mike and Michal pointed, default_hstate is defined as
> > #define default_hstate (hstates[default_hstate_idx]),
> > where default_hstate_idx can be altered by a boot argument.
> >
> > We're iterating over all states to calculate total and also
> > print some additional info for the default size. Having a single
> > loop guarantees consistency of these numbers.
> >
>
> OK, I misread the handling of `count' -> HugePages_Total.
>
> It seems unnecessarily obscure?
>
> for_each_hstate(h) {
> unsigned long count = h->nr_huge_pages;
>
> total += (PAGE_SIZE << huge_page_order(h)) * count;
>
> if (h == &default_hstate)
> seq_printf(m,
> "HugePages_Total: %5lu\n"
> "HugePages_Free: %5lu\n"
> "HugePages_Rsvd: %5lu\n"
> "HugePages_Surp: %5lu\n"
> "Hugepagesize: %8lu kB\n",
> count,
> h->free_huge_pages,
> h->resv_huge_pages,
> h->surplus_huge_pages,
> (PAGE_SIZE << huge_page_order(h)) / 1024);
> }
>
> seq_printf(m, "Hugetlb: %8lu kB\n", total / 1024);
>
>
> Why not
>
> seq_printf(m,
> "HugePages_Total: %5lu\n"
> "HugePages_Free: %5lu\n"
> "HugePages_Rsvd: %5lu\n"
> "HugePages_Surp: %5lu\n"
> "Hugepagesize: %8lu kB\n",
> h->nr_huge_pages,
> h->free_huge_pages,
> h->resv_huge_pages,
> h->surplus_huge_pages,
> 1UL << (huge_page_order(h) + PAGE_SHIFT - 10));
>
> for_each_hstate(h)
> total += (PAGE_SIZE << huge_page_order(h)) * h->nr_huge_pages;
> seq_printf(m, "Hugetlb: %8lu kB\n", total / 1024);
>
> ?
The idea was that the local variable guarantees the consistency
between Hugetlb and HugePages_Total numbers. Otherwise we have
to take hugetlb_lock.
What we can do, is to rename "count" into "nr_huge_pages", like:
for_each_hstate(h) {
unsigned long nr_huge_pages = h->nr_huge_pages;
total += (PAGE_SIZE << huge_page_order(h)) * nr_huge_pages;
if (h == &default_hstate)
seq_printf(m,
"HugePages_Total: %5lu\n"
"HugePages_Free: %5lu\n"
"HugePages_Rsvd: %5lu\n"
"HugePages_Surp: %5lu\n"
"Hugepagesize: %8lu kB\n",
nr_huge_pages,
h->free_huge_pages,
h->resv_huge_pages,
h->surplus_huge_pages,
(PAGE_SIZE << huge_page_order(h)) / 1024);
}
seq_printf(m, "Hugetlb: %8lu kB\n", total / 1024);
But maybe taking a lock is not a bad idea, because it will also
guarantee consistency between other numbers (like HugePages_Free) as well,
which is not true right now.
Thanks!
next prev parent reply other threads:[~2017-11-21 20:00 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-15 23:14 [PATCH v2] mm: show total hugetlb memory consumption in /proc/meminfo Roman Gushchin
2017-11-15 23:14 ` Roman Gushchin
2017-11-16 9:11 ` Michal Hocko
2017-11-16 9:11 ` Michal Hocko
2017-11-16 14:22 ` Johannes Weiner
2017-11-16 14:22 ` Johannes Weiner
2017-11-17 9:41 ` David Rientjes
2017-11-17 9:41 ` David Rientjes
2017-11-21 0:51 ` Andrew Morton
2017-11-21 0:51 ` Andrew Morton
2017-11-21 1:09 ` Mike Kravetz
2017-11-21 1:09 ` Mike Kravetz
2017-11-21 7:01 ` Michal Hocko
2017-11-21 7:01 ` Michal Hocko
2017-11-21 15:15 ` Roman Gushchin
2017-11-21 15:15 ` Roman Gushchin
2017-11-21 19:19 ` Andrew Morton
2017-11-21 19:19 ` Andrew Morton
2017-11-21 19:59 ` Roman Gushchin [this message]
2017-11-21 19:59 ` Roman Gushchin
2017-11-22 0:27 ` Mike Kravetz
2017-11-22 0:27 ` Mike Kravetz
2017-11-22 9:10 ` Michal Hocko
2017-11-22 9:10 ` Michal Hocko
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=20171121195947.GA12709@castle \
--to=guro@fb.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=dave.hansen@intel.com \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=mike.kravetz@oracle.com \
--cc=rientjes@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.