[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210510102312.GC22664@linux>
Date: Mon, 10 May 2021 12:23:12 +0200
From: Oscar Salvador <osalvador@...e.de>
To: Muchun Song <songmuchun@...edance.com>
Cc: corbet@....net, mike.kravetz@...cle.com, tglx@...utronix.de,
mingo@...hat.com, bp@...en8.de, x86@...nel.org, hpa@...or.com,
dave.hansen@...ux.intel.com, luto@...nel.org, peterz@...radead.org,
viro@...iv.linux.org.uk, akpm@...ux-foundation.org,
paulmck@...nel.org, pawan.kumar.gupta@...ux.intel.com,
rdunlap@...radead.org, oneukum@...e.com, anshuman.khandual@....com,
jroedel@...e.de, almasrymina@...gle.com, rientjes@...gle.com,
willy@...radead.org, mhocko@...e.com, song.bao.hua@...ilicon.com,
david@...hat.com, naoya.horiguchi@....com,
joao.m.martins@...cle.com, duanxiongchun@...edance.com,
fam.zheng@...edance.com, zhengqi.arch@...edance.com,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v23 5/9] mm: hugetlb: defer freeing of HugeTLB pages
On Mon, May 10, 2021 at 11:00:23AM +0800, Muchun Song wrote:
> In the subsequent patch, we should allocate the vmemmap pages when
> freeing a HugeTLB page. But update_and_free_page() can be called
> under any context, so we cannot use GFP_KERNEL to allocate vmemmap
> pages. However, we can defer the actual freeing in a kworker to
> prevent from using GFP_ATOMIC to allocate the vmemmap pages.
>
> The __update_and_free_page() is where the call to allocate vmemmmap
> pages will be inserted.
>
> Signed-off-by: Muchun Song <songmuchun@...edance.com>
> Reviewed-by: Mike Kravetz <mike.kravetz@...cle.com>
Reviewed-by: Oscar Salvador <osalvador@...e.de>
--
Oscar Salvador
SUSE L3
Powered by blists - more mailing lists