Thread (37 messages) 37 messages, 4 authors, 2021-02-18

Re: [External] Re: [PATCH v15 4/8] mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page

From: Muchun Song <hidden>
Date: 2021-02-18 03:22:11
Also in: linux-fsdevel, linux-mm, lkml

On Thu, Feb 18, 2021 at 9:00 AM Mike Kravetz [off-list ref] wrote:
On 2/17/21 12:13 AM, Michal Hocko wrote:
quoted
On Tue 16-02-21 11:44:34, Mike Kravetz wrote:
[...]
quoted
If we are not going to do the allocations under the lock, then we will need
to either preallocate or take the workqueue approach.
We can still drop the lock temporarily right? As we already do before
calling destroy_compound_gigantic_page...
Yes we can.  I forgot about that.

Actually, very little of what update_and_free_page does needs to be done
under the lock.  Perhaps, just decrementing the global count and clearing
the destructor so PageHuge() is no longer true.
Right. I have another question about using GFP flags. Michal
suggested using GFP_KERNEL instead of GFP_ATOMIC to
save reserve memory. From your last email, you suggested
using non-blocking allocation GFP flags (perhaps GFP_NOWAIT).

Hi Mike and Michal,

What is the consensus we finally reached? Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help