Messages in this thread | | | From | Muchun Song <> | Date | Thu, 18 Feb 2021 11:20:51 +0800 | Subject | Re: [External] Re: [PATCH v15 4/8] mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page |
| |
On Thu, Feb 18, 2021 at 9:00 AM Mike Kravetz <mike.kravetz@oracle.com> wrote: > > On 2/17/21 12:13 AM, Michal Hocko wrote: > > On Tue 16-02-21 11:44:34, Mike Kravetz wrote: > > [...] > >> 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.
| |