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