linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Muchun Song <songmuchun@bytedance.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	mingo@redhat.com, bp@alien8.de,  x86@kernel.org, hpa@zytor.com,
	dave.hansen@linux.intel.com, luto@kernel.org,
	 Peter Zijlstra <peterz@infradead.org>,
	viro@zeniv.linux.org.uk,
	 Andrew Morton <akpm@linux-foundation.org>,
	paulmck@kernel.org, mchehab+huawei@kernel.org,
	 pawan.kumar.gupta@linux.intel.com,
	Randy Dunlap <rdunlap@infradead.org>,
	oneukum@suse.com,  anshuman.khandual@arm.com, jroedel@suse.de,
	 Mina Almasry <almasrymina@google.com>,
	David Rientjes <rientjes@google.com>,
	linux-doc@vger.kernel.org,  LKML <linux-kernel@vger.kernel.org>,
	 Linux Memory Management List <linux-mm@kvack.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [External] Re: [RFC PATCH 05/24] mm/hugetlb: Introduce nr_free_vmemmap_pages in the struct hstate
Date: Thu, 1 Oct 2020 10:57:38 +0800	[thread overview]
Message-ID: <CAMZfGtV99X7TbkortsFaUYQC-Zvq53ggwB_PBzqUBFyQ2Hkvpg@mail.gmail.com> (raw)
In-Reply-To: <b2811679-cd90-4685-2284-64490e7dfb7e@oracle.com>

On Thu, Oct 1, 2020 at 6:41 AM Mike Kravetz <mike.kravetz@oracle.com> wrote:
>
> On 9/15/20 5:59 AM, Muchun Song wrote:
> > If the size of hugetlb page is 2MB, we need 512 struct page structures
> > (8 pages) to be associated with it. As far as I know, we only use the
> > first 3 struct page structures and only read the compound_dtor members
>
> Actually, the first 4 pages can be used if CONFIG_CGROUP_HUGETLB.

Right, thanks.

> /*
>  * Minimum page order trackable by hugetlb cgroup.
>  * At least 4 pages are necessary for all the tracking information.
>  * The second tail page (hpage[2]) is the fault usage cgroup.
>  * The third tail page (hpage[3]) is the reservation usage cgroup.
>  */
> #define HUGETLB_CGROUP_MIN_ORDER        2
>
> However, this still easily fits within the first page of struct page
> structures.
>
> > of the remaining struct page structures. For tail page, the value of
> > compound_dtor is the same. So we can reuse first tail page. We map the
> > virtual addresses of the remaining 6 tail pages to the first tail page,
> > and then free these 6 pages. Therefore, we need to reserve at least 2
> > pages as vmemmap areas.
>
> I got confused the first time I read the above sentences.  Perhaps it
> should be more explicit with something like:
>
> For tail pages, the value of compound_dtor is the same. So we can reuse
> first page of tail page structs. We map the virtual addresses of the
> remaining 6 pages of tail page structs to the first tail page struct,
> and then free these 6 pages. Therefore, we need to reserve at least 2
> pages as vmemmap areas.

Sorry for my poor English. Thanks for your suggestions. I can apply this.

>
> It still does not sound great, but hopefully avoids some confusion.
> --
> Mike Kravetz
>
> > So we introduce a new nr_free_vmemmap_pages field in the hstate to
> > indicate how many vmemmap pages associated with a hugetlb page that we
> > can free to buddy system.
> >
> > Signed-off-by: Muchun Song <songmuchun@bytedance.com>
> > ---
> >  include/linux/hugetlb.h |  3 +++
> >  mm/hugetlb.c            | 35 +++++++++++++++++++++++++++++++++++
> >  2 files changed, 38 insertions(+)
> >
> > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> > index d5cc5f802dd4..eed3dd3bd626 100644
> > --- a/include/linux/hugetlb.h
> > +++ b/include/linux/hugetlb.h
> > @@ -492,6 +492,9 @@ struct hstate {
> >       unsigned int nr_huge_pages_node[MAX_NUMNODES];
> >       unsigned int free_huge_pages_node[MAX_NUMNODES];
> >       unsigned int surplus_huge_pages_node[MAX_NUMNODES];
> > +#ifdef CONFIG_HUGETLB_PAGE_FREE_VMEMMAP
> > +     unsigned int nr_free_vmemmap_pages;
> > +#endif
> >  #ifdef CONFIG_CGROUP_HUGETLB
> >       /* cgroup control files */
> >       struct cftype cgroup_files_dfl[7];
> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > index 81a41aa080a5..f1b2b733b49b 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> > @@ -1292,6 +1292,39 @@ static inline void destroy_compound_gigantic_page(struct page *page,
> >                                               unsigned int order) { }
> >  #endif
> >
> > +#ifdef CONFIG_HUGETLB_PAGE_FREE_VMEMMAP
> > +#define RESERVE_VMEMMAP_NR   2U
> > +
> > +static inline unsigned int nr_free_vmemmap(struct hstate *h)
> > +{
> > +     return h->nr_free_vmemmap_pages;
> > +}
> > +
> > +static void __init hugetlb_vmemmap_init(struct hstate *h)
> > +{
> > +     unsigned int order = huge_page_order(h);
> > +     unsigned int vmemmap_pages;
> > +
> > +     vmemmap_pages = ((1 << order) * sizeof(struct page)) >> PAGE_SHIFT;
> > +     /*
> > +      * The head page and the first tail page not free to buddy system,
> > +      * the others page will map to the first tail page. So there are
> > +      * (@vmemmap_pages - RESERVE_VMEMMAP_NR) pages can be freed.
> > +      */
> > +     if (vmemmap_pages > RESERVE_VMEMMAP_NR)
> > +             h->nr_free_vmemmap_pages = vmemmap_pages - RESERVE_VMEMMAP_NR;
> > +     else
> > +             h->nr_free_vmemmap_pages = 0;
> > +
> > +     pr_info("HugeTLB: can free %d vmemmap pages for %s\n",
> > +             h->nr_free_vmemmap_pages, h->name);
> > +}
> > +#else
> > +static inline void hugetlb_vmemmap_init(struct hstate *h)
> > +{
> > +}
> > +#endif
> > +
> >  static void update_and_free_page(struct hstate *h, struct page *page)
> >  {
> >       int i;
> > @@ -3285,6 +3318,8 @@ void __init hugetlb_add_hstate(unsigned int order)
> >       snprintf(h->name, HSTATE_NAME_LEN, "hugepages-%lukB",
> >                                       huge_page_size(h)/1024);
> >
> > +     hugetlb_vmemmap_init(h);
> > +
> >       parsed_hstate = h;
> >  }
> >
> >



-- 
Yours,
Muchun


  reply	other threads:[~2020-10-01  2:58 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-15 12:59 [RFC PATCH 00/24] mm/hugetlb: Free some vmemmap pages of hugetlb page Muchun Song
2020-09-15 12:59 ` [RFC PATCH 01/24] mm/memory_hotplug: Move bootmem info registration API to bootmem_info.c Muchun Song
2020-09-29 22:46   ` Mike Kravetz
2020-09-15 12:59 ` [RFC PATCH 02/24] mm/memory_hotplug: Move {get,put}_page_bootmem() " Muchun Song
2020-09-29 23:30   ` Mike Kravetz
2020-09-15 12:59 ` [RFC PATCH 03/24] mm/hugetlb: Introduce a new config HUGETLB_PAGE_FREE_VMEMMAP Muchun Song
2020-09-16  2:13   ` Randy Dunlap
2020-09-29 23:41   ` Mike Kravetz
2020-09-30  2:56     ` [External] " Muchun Song
2020-09-15 12:59 ` [RFC PATCH 04/24] mm/hugetlb: Register bootmem info when CONFIG_HUGETLB_PAGE_FREE_VMEMMAP Muchun Song
2020-09-15 12:59 ` [RFC PATCH 05/24] mm/hugetlb: Introduce nr_free_vmemmap_pages in the struct hstate Muchun Song
2020-09-30 22:41   ` Mike Kravetz
2020-10-01  2:57     ` Muchun Song [this message]
2020-09-15 12:59 ` [RFC PATCH 06/24] mm/hugetlb: Introduce pgtable allocation/freeing helpers Muchun Song
2020-09-15 12:59 ` [RFC PATCH 07/24] mm/hugetlb: Add freeing unused vmemmap pages support for x86 Muchun Song
2020-09-15 12:59 ` [RFC PATCH 08/24] mm/bootmem_info: Introduce {free,prepare}_vmemmap_page() Muchun Song
2020-09-15 12:59 ` [RFC PATCH 09/24] x86/mm: Introduce VMEMMAP_SIZE/VMEMMAP_END macro Muchun Song
2020-09-15 12:59 ` [RFC PATCH 10/24] mm/hugetlb: Free the vmemmap pages associated with each hugetlb page Muchun Song
2020-09-15 12:59 ` [RFC PATCH 11/24] mm/hugetlb: Add vmemmap_pmd_huge macro for x86 Muchun Song
2020-09-15 12:59 ` [RFC PATCH 12/24] mm/hugetlb: Defer freeing of hugetlb pages Muchun Song
2020-09-15 12:59 ` [RFC PATCH 13/24] mm/hugetlb: Allocate the vmemmap pages associated with each hugetlb page Muchun Song
2020-09-15 12:59 ` [RFC PATCH 14/24] mm/hugetlb: Introduce remap_huge_page_pmd_vmemmap helper Muchun Song
2020-09-15 12:59 ` [RFC PATCH 15/24] mm/hugetlb: Use PG_slab to indicate split pmd Muchun Song
2020-09-15 12:59 ` [RFC PATCH 16/24] mm/hugetlb: Support freeing vmemmap pages of gigantic page Muchun Song
2020-09-15 12:59 ` [RFC PATCH 17/24] mm/hugetlb: Add a BUILD_BUG_ON to check if struct page size is a power of two Muchun Song
2020-09-15 12:59 ` [RFC PATCH 18/24] mm/hugetlb: Clear PageHWPoison on the non-error memory page Muchun Song
2020-09-15 12:59 ` [RFC PATCH 19/24] mm/hugetlb: Flush work when dissolving hugetlb page Muchun Song
2020-09-15 12:59 ` [RFC PATCH 20/24] mm/hugetlb: Add a kernel parameter hugetlb_free_vmemmap Muchun Song
2020-09-16  2:10   ` Randy Dunlap
2020-09-16  2:50     ` [External] " Muchun Song
2020-09-15 12:59 ` [RFC PATCH 21/24] mm/hugetlb: Merge pte to huge pmd only for gigantic page Muchun Song
2020-09-20  9:59   ` Muchun Song
2020-09-15 12:59 ` [RFC PATCH 22/24] mm/hugetlb: Implement vmemmap_pmd_mkhuge macro Muchun Song
2020-09-15 12:59 ` [RFC PATCH 23/24] mm/hugetlb: Gather discrete indexes of tail page Muchun Song
2020-09-15 12:59 ` [RFC PATCH 24/24] mm/hugetlb: Add BUILD_BUG_ON to catch invalid usage of tail struct page Muchun Song
2020-09-15 14:32 ` [RFC PATCH 00/24] mm/hugetlb: Free some vmemmap pages of hugetlb page Matthew Wilcox
2020-09-15 14:53   ` Dave Hansen
2020-09-15 15:28   ` [External] " Muchun Song
2020-09-15 15:42     ` Matthew Wilcox
2020-09-15 17:32       ` Muchun Song
2020-09-15 17:39         ` Matthew Wilcox
2020-09-15 18:03           ` Muchun Song
2020-09-15 18:15             ` Matthew Wilcox
2020-09-16  2:45               ` Muchun Song
2020-09-29 21:58 ` Mike Kravetz
2020-09-30  3:13   ` Matthew Wilcox
2020-10-07 21:12   ` Mike Kravetz
2020-10-09  4:13     ` [External] " Muchun Song

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=CAMZfGtV99X7TbkortsFaUYQC-Zvq53ggwB_PBzqUBFyQ2Hkvpg@mail.gmail.com \
    --to=songmuchun@bytedance.com \
    --cc=akpm@linux-foundation.org \
    --cc=almasrymina@google.com \
    --cc=anshuman.khandual@arm.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jroedel@suse.de \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mchehab+huawei@kernel.org \
    --cc=mike.kravetz@oracle.com \
    --cc=mingo@redhat.com \
    --cc=oneukum@suse.com \
    --cc=paulmck@kernel.org \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=rientjes@google.com \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    --cc=x86@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).