All of lore.kernel.org
 help / color / mirror / Atom feed
From: Muchun Song <songmuchun@bytedance.com>
To: Jonathan Corbet <corbet@lwn.net>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	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>
Cc: 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: [RFC PATCH 21/24] mm/hugetlb: Merge pte to huge pmd only for gigantic page
Date: Sun, 20 Sep 2020 17:59:01 +0800	[thread overview]
Message-ID: <CAMZfGtWXr0A3ymf_trBmUggRudbZbhfwNCJWSHZdkK9JeBY1fg@mail.gmail.com> (raw)
In-Reply-To: <20200915125947.26204-22-songmuchun@bytedance.com>

On Tue, Sep 15, 2020 at 9:03 PM Muchun Song <songmuchun@bytedance.com> wrote:
>
> Merge pte to huge pmd if it has ever been split. Now only support
> gigantic page which's vmemmap pages size is an integer multiple of
> PMD_SIZE. This is the simplest case to handle.
>
> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
> ---
>  include/linux/hugetlb.h |   7 +++
>  mm/hugetlb.c            | 104 +++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 109 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index e3aa192f1c39..c56df0da7ae5 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -611,6 +611,13 @@ static inline bool vmemmap_pmd_huge(pmd_t *pmd)
>  }
>  #endif
>
> +#ifndef vmemmap_pmd_mkhuge
> +static inline pmd_t vmemmap_pmd_mkhuge(struct page *page)
> +{
> +       return pmd_mkhuge(mk_pmd(page, PAGE_KERNEL));
> +}
> +#endif
> +
>  #ifndef VMEMMAP_HPAGE_SHIFT
>  #define VMEMMAP_HPAGE_SHIFT            PMD_SHIFT
>  #endif
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 28c154679838..3ca36e259b4e 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1759,6 +1759,62 @@ static void __remap_huge_page_pte_vmemmap(struct page *reuse, pte_t *ptep,
>         }
>  }
>
> +static void __replace_huge_page_pte_vmemmap(pte_t *ptep, unsigned long start,
> +                                           unsigned int nr, struct page *huge,
> +                                           struct list_head *free_pages)
> +{
> +       unsigned long addr;
> +       unsigned long end = start + (nr  << PAGE_SHIFT);
> +
> +       for (addr = start; addr < end; addr += PAGE_SIZE, ptep++) {
> +               struct page *page;
> +               pte_t old = *ptep;
> +               pte_t entry;
> +
> +               prepare_vmemmap_page(huge);
> +
> +               entry = mk_pte(huge++, PAGE_KERNEL);
> +               VM_WARN_ON(!pte_present(old));
> +               page = pte_page(old);
> +               list_add(&page->lru, free_pages);
> +
> +               set_pte_at(&init_mm, addr, ptep, entry);
> +       }
> +}
> +
> +static void replace_huge_page_pmd_vmemmap(pmd_t *pmd, unsigned long start,
> +                                         struct page *huge,
> +                                         struct list_head *free_pages)
> +{
> +       unsigned long end = start + VMEMMAP_HPAGE_SIZE;
> +
> +       flush_cache_vunmap(start, end);
> +       __replace_huge_page_pte_vmemmap(pte_offset_kernel(pmd, start), start,
> +                                       VMEMMAP_HPAGE_NR, huge, free_pages);
> +       flush_tlb_kernel_range(start, end);
> +}
> +
> +static pte_t *merge_vmemmap_pte(pmd_t *pmdp, unsigned long addr)
> +{
> +       pte_t *pte;
> +       struct page *page;
> +
> +       pte = pte_offset_kernel(pmdp, addr);
> +       page = pte_page(*pte);
> +       set_pmd(pmdp, vmemmap_pmd_mkhuge(page));
> +
> +       return pte;
> +}
> +
> +static void merge_huge_page_pmd_vmemmap(pmd_t *pmd, unsigned long start,
> +                                       struct page *huge,
> +                                       struct list_head *free_pages)
> +{
> +       replace_huge_page_pmd_vmemmap(pmd, start, huge, free_pages);
> +       pte_free_kernel(&init_mm, merge_vmemmap_pte(pmd, start));
> +       flush_tlb_kernel_range(start, start + VMEMMAP_HPAGE_SIZE);
> +}
> +
>  static inline void alloc_vmemmap_pages(struct hstate *h, struct list_head *list)
>  {
>         int i;
> @@ -1772,6 +1828,15 @@ static inline void alloc_vmemmap_pages(struct hstate *h, struct list_head *list)
>         }
>  }
>
> +static inline void dissolve_compound_page(struct page *page, unsigned int order)
> +{
> +       int i;
> +       unsigned int nr_pages = 1 << order;
> +
> +       for (i = 1; i < nr_pages; i++)
> +               set_page_refcounted(page + i);
> +}
> +
>  static void alloc_huge_page_vmemmap(struct hstate *h, struct page *head)
>  {
>         pmd_t *pmd;
> @@ -1791,10 +1856,45 @@ static void alloc_huge_page_vmemmap(struct hstate *h, struct page *head)
>                                     __remap_huge_page_pte_vmemmap);
>         if (!freed_vmemmap_hpage_dec(pmd_page(*pmd)) && pmd_split(pmd)) {
>                 /*
> -                * Todo:
> -                * Merge pte to huge pmd if it has ever been split.
> +                * Merge pte to huge pmd if it has ever been split. Now only
> +                * support gigantic page which's vmemmap pages size is an
> +                * integer multiple of PMD_SIZE. This is the simplest case
> +                * to handle.
>                  */
>                 clear_pmd_split(pmd);
> +
> +               if (IS_ALIGNED(nr_vmemmap(h), VMEMMAP_HPAGE_NR)) {
> +                       unsigned long addr = (unsigned long)head;
> +                       unsigned long end = addr + nr_vmemmap_size(h);
> +
> +                       spin_unlock(ptl);
> +
> +                       for (; addr < end; addr += VMEMMAP_HPAGE_SIZE) {
> +                               void *to;
> +                               struct page *page;
> +
> +                               page = alloc_pages(GFP_VMEMMAP_PAGE & ~__GFP_NOFAIL,
> +                                                  VMEMMAP_HPAGE_ORDER);
> +                               if (!page)
> +                                       goto out;

Here forget to call dissolve_compound_page().

+                               dissolve_compound_page(page,
+                                                      VMEMMAP_HPAGE_ORDER);

> +
> +                               to = page_to_virt(page);
> +                               memcpy(to, (void *)addr, VMEMMAP_HPAGE_SIZE);
> +
> +                               /*
> +                                * Make sure that any data that writes to the
> +                                * @to is made visible to the physical page.
> +                                */
> +                               flush_kernel_vmap_range(to, VMEMMAP_HPAGE_SIZE);
> +
> +                               merge_huge_page_pmd_vmemmap(pmd++, addr, page,
> +                                                           &remap_pages);
> +                       }
> +
> +out:
> +                       free_vmemmap_page_list(&remap_pages);
> +                       return;
> +               }
>         }
>         spin_unlock(ptl);
>  }
> --
> 2.20.1
>


-- 
Yours,
Muchun

  reply	other threads:[~2020-09-20  9:59 UTC|newest]

Thread overview: 57+ 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-30  2:56       ` 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     ` [External] " Muchun Song
2020-10-01  2:57       ` Muchun Song
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-16  2:50       ` 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 [this message]
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:28     ` Muchun Song
2020-09-15 15:42     ` Matthew Wilcox
2020-09-15 17:32       ` Muchun Song
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:03             ` Muchun Song
2020-09-15 18:15             ` Matthew Wilcox
2020-09-16  2:45               ` Muchun Song
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
2020-10-09  4:13       ` 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=CAMZfGtWXr0A3ymf_trBmUggRudbZbhfwNCJWSHZdkK9JeBY1fg@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 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.