Re: [PATCH v6 09/16] mm/hugetlb: Defer freeing of HugeTLB pages

[Michal Hocko <mhocko@suse.com>]

On Tue 24-11-20 17:52:52, Muchun Song wrote:
> In the subsequent patch, we will allocate the vmemmap pages when free
> HugeTLB pages. But update_and_free_page() is called from a non-task
> context(and hold hugetlb_lock), so we can defer the actual freeing in
> a workqueue to prevent use GFP_ATOMIC to allocate the vmemmap pages.

This has been brought up earlier without any satisfying answer. Do we
really have bother with the freeing from the pool and reconstructing the
vmemmap page tables? Do existing usecases really require such a dynamic
behavior? In other words, wouldn't it be much simpler to allow to use
hugetlb pages with sparse vmemmaps only for the boot time reservations
and never allow them to be freed back to the allocator. This is pretty
restrictive, no question about that, but it would drop quite some code
AFAICS and the resulting series would be much easier to review really
carefully. Additional enhancements can be done on top with specifics
about usecases which require more flexibility.

> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
> ---
>  mm/hugetlb.c         | 96 ++++++++++++++++++++++++++++++++++++++++++++++------
>  mm/hugetlb_vmemmap.c |  5 ---
>  mm/hugetlb_vmemmap.h | 10 ++++++
>  3 files changed, 95 insertions(+), 16 deletions(-)
-- 
Michal Hocko
SUSE Labs