This effort is the result a recent bug report [1]. In subsequent discussions [2], it was deemed necessary to properly fix the hugetlb put_page path (free_huge_page). This RFC provides a possible way to address the issue. Comments are welcome/encouraged as several attempts at this have been made in the past. This series is based on v5.12-rc3. At a high level, this series does: - Patches 1 & 2 are cleanups/fixes to existing code in the areas to be modified. - Patches 3, 4 & 5 are aimed at reducing lock hold times. To be clear the goal is to eliminate single lock hold times of a long duration. Overall lock hold time is not addressed. In addition, the known long hold time in hugetlb_cgroup_css_offline still needs to be addressed (suggestions welcome). - Patch 6 makes hugetlb_lock and subpool lock IRQ safe. It also reverts the code which defers calls to a workqueue if !in_task. - Patch 7 adds code to defer freeing of pages to a workqueue if the freeing routines could possibly sleep. - Patch 8 adds a flag to gigantic pages allocated from CMA so that we only defer freeing those pages. [1] https://lore.kernel.org/linux-mm/000000000000f1c03b05bc43aadc@xxxxxxxxxx/ [2] http://lkml.kernel.org/r/20210311021321.127500-1-mike.kravetz@xxxxxxxxxx Mike Kravetz (8): hugetlb: add per-hstate mutex to synchronize user adjustments hugetlb: recompute min_count when dropping hugetlb_lock hugetlb: create remove_hugetlb_page() to separate functionality hugetlb: call update_and_free_page without hugetlb_lock hugetlb: change free_pool_huge_page to remove_pool_huge_page hugetlb: make free_huge_page irq safe hugetlb: add update_and_free_page_no_sleep for irq context hugetlb: track hugetlb pages allocated via cma_alloc include/linux/hugetlb.h | 20 +- mm/hugetlb.c | 450 +++++++++++++++++++++++++--------------- mm/hugetlb_cgroup.c | 10 +- 3 files changed, 310 insertions(+), 170 deletions(-) -- 2.30.2
