Re: [PATCH v18 4/9] mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux