Re: [External] Re: [PATCH v4 05/21] mm/hugetlb: Introduce pgtable allocation/freeing helpers

From: Muchun Song
Date: Tue Nov 17 2020 - 10:30:28 EST


On Tue, Nov 17, 2020 at 11:06 PM Oscar Salvador <osalvador@xxxxxxx> wrote:
>
> On Fri, Nov 13, 2020 at 06:59:36PM +0800, Muchun Song wrote:
> > +#define page_huge_pte(page) ((page)->pmd_huge_pte)

Yeah, I forgot to remove it. Thanks.

>
> Seems you do not need this one anymore.
>
> > +void vmemmap_pgtable_free(struct page *page)
> > +{
> > + struct page *pte_page, *t_page;
> > +
> > + list_for_each_entry_safe(pte_page, t_page, &page->lru, lru) {
> > + list_del(&pte_page->lru);
> > + pte_free_kernel(&init_mm, page_to_virt(pte_page));
> > + }
> > +}
> > +
> > +int vmemmap_pgtable_prealloc(struct hstate *h, struct page *page)
> > +{
> > + unsigned int nr = pgtable_pages_to_prealloc_per_hpage(h);
> > +
> > + /* Store preallocated pages on huge page lru list */
> > + INIT_LIST_HEAD(&page->lru);
> > +
> > + while (nr--) {
> > + pte_t *pte_p;
> > +
> > + pte_p = pte_alloc_one_kernel(&init_mm);
> > + if (!pte_p)
> > + goto out;
> > + list_add(&virt_to_page(pte_p)->lru, &page->lru);
> > + }
>
> Definetely this looks better and easier to handle.
> Btw, did you explore Matthew's hint about instead of allocating a new page,
> using one of the ones you are going to free to store the ptes?

Oh, sorry for missing his reply. It is a good idea. I will start an
investigation.
Thanks for reminding me.

> I am not sure whether it is feasible at all though.
>
>
> > --- a/mm/hugetlb_vmemmap.h
> > +++ b/mm/hugetlb_vmemmap.h
> > @@ -9,12 +9,24 @@
> > #ifndef _LINUX_HUGETLB_VMEMMAP_H
> > #define _LINUX_HUGETLB_VMEMMAP_H
> > #include <linux/hugetlb.h>
> > +#include <linux/mm.h>
>
> why do we need this here?

Yeah, also can remove:).


>
> --
> Oscar Salvador
> SUSE L3



--
Yours,
Muchun