The patch titled
Subject: hugetlb: fix comments about avoiding atomic allocation of vmemmap pages
has been added to the -mm tree. Its filename is
hugetlb-fix-comments-about-avoiding-atomic-allocation-of-vmemmap-pages.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/hugetlb-fix-comments-about-avoiding-atomic-allocation-of-vmemmap-pages.patch
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/hugetlb-fix-comments-about-avoiding-atomic-allocation-of-vmemmap-pages.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: luofei <luofei@xxxxxxxxxxxx>
Subject: hugetlb: fix comments about avoiding atomic allocation of vmemmap pages
Since there is no longer an atomic allocation of vmemmap pages, but a
fixed flag(GFP_KERNEL | __GFP_NORETRY | __GFP_THISNODE) is used. The
description of atomicity here is some what inappropriate.
And the atomic parameter naming of update_and_free_page() may be
misleading, add a comment here.
Link: https://lkml.kernel.org/r/20220316031602.377452-1-luofei@xxxxxxxxxxxx
Signed-off-by: luofei <luofei@xxxxxxxxxxxx>
Reviewed-by: Muchun Song <songmuchun@xxxxxxxxxxxxx>
Cc: Mike Kravetz <mike.kravetz@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/hugetlb.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
--- a/mm/hugetlb.c~hugetlb-fix-comments-about-avoiding-atomic-allocation-of-vmemmap-pages
+++ a/mm/hugetlb.c
@@ -1567,10 +1567,12 @@ static void __update_and_free_page(struc
}
/*
- * As update_and_free_page() can be called under any context, so we cannot
- * use GFP_KERNEL to allocate vmemmap pages. However, we can defer the
- * actual freeing in a workqueue to prevent from using GFP_ATOMIC to allocate
- * the vmemmap pages.
+ * Freeing hugetlb pages in done in update_and_free_page(). When freeing
+ * a hugetlb page, vmemmap pages may need to be allocated. The routine
+ * alloc_huge_page_vmemmap() can possibly sleep as it uses GFP_KERNEL.
+ * However, update_and_free_page() can be called under any context. To
+ * avoid the possibility of sleeping in a context where sleeping is not
+ * allowed, defer the actual freeing in a workqueue where sleeping is allowed.
*
* free_hpage_workfn() locklessly retrieves the linked list of pages to be
* freed and frees them one-by-one. As the page->mapping pointer is going
@@ -1614,6 +1616,10 @@ static inline void flush_free_hpage_work
flush_work(&free_hpage_work);
}
+/*
+ * atomic == true indicates called from a context where sleeping is
+ * not allowed.
+ */
static void update_and_free_page(struct hstate *h, struct page *page,
bool atomic)
{
@@ -1623,7 +1629,8 @@ static void update_and_free_page(struct
}
/*
- * Defer freeing to avoid using GFP_ATOMIC to allocate vmemmap pages.
+ * Defer freeing to avoid possible sleeping when allocating
+ * vmemmap pages.
*
* Only call schedule_work() if hpage_freelist is previously
* empty. Otherwise, schedule_work() had been called but the workfn
_
Patches currently in -mm which might be from luofei@xxxxxxxxxxxx are
mm-hwpoison-avoid-the-impact-of-hwpoison_filter-return-value-on-mce-handler.patch
mm-hwpoison-add-in-use-hugepage-hwpoison-filter-judgement.patch
hugetlb-fix-comments-about-avoiding-atomic-allocation-of-vmemmap-pages.patch
