lkml.org 
[lkml]   [2021]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v18 4/9] mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page
From
Date
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

\
 
 \ /
  Last update: 2021-03-11 19:02    [W:0.077 / U:0.428 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site