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@xxxxxxxxxxxxx> > --- > 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
