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

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

 



On Thu, Feb 18, 2021 at 9:00 AM Mike Kravetz <mike.kravetz@xxxxxxxxxx> 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.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux