Messages in this thread | | | Subject | Re: [PATCH v18 4/9] mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page | From | Mike Kravetz <> | Date | Thu, 11 Mar 2021 09:59:53 -0800 |
| |
On 3/11/21 4:17 AM, Michal Hocko wrote: >> Yeah per cpu preempt counting shouldn't be noticeable but I have to >> confess I haven't benchmarked it. > > But all this seems moot now http://lkml.kernel.org/r/YEoA08n60+jzsnAl@hirez.programming.kicks-ass.net >
The proper fix for free_huge_page independent of this series would involve:
- Make hugetlb_lock and subpool lock irq safe - Hand off freeing to a workque if the freeing could sleep
Today, the only time we can sleep in free_huge_page is for gigantic pages allocated via cma. I 'think' the concern about undesirable user visible side effects in this case is minimal as freeing/allocating 1G pages is not something that is going to happen at a high frequency. My thinking could be wrong?
Of more concern, is the introduction of this series. If this feature is enabled, then ALL free_huge_page requests must be sent to a workqueue. Any ideas on how to address this? -- Mike Kravetz
| |