[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMZfGtUeL45=WG3ceaZ_tALMGZTLtuD9jbfKEzeQv270OnaLYQ@mail.gmail.com>
Date: Mon, 8 Nov 2021 16:16:50 +0800
From: Muchun Song <songmuchun@...edance.com>
To: Mike Kravetz <mike.kravetz@...cle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Oscar Salvador <osalvador@...e.de>,
Michal Hocko <mhocko@...e.com>,
David Hildenbrand <david@...hat.com>,
Jonathan Corbet <corbet@....net>,
Matthew Wilcox <willy@...radead.org>
Cc: Xiongchun duan <duanxiongchun@...edance.com>,
fam.zheng@...edance.com, Muchun Song <smuchun@...il.com>,
Qi Zheng <zhengqi.arch@...edance.com>,
linux-doc@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
Linux Memory Management List <linux-mm@...ck.org>,
"Song Bao Hua (Barry Song)" <song.bao.hua@...ilicon.com>,
Barry Song <21cnbao@...il.com>,
Chen Huang <chenhuang5@...wei.com>,
"Bodeddula, Balasubramaniam" <bodeddub@...zon.com>
Subject: Re: [PATCH v7 0/5] Free the 2nd vmemmap page associated with each
HugeTLB page
On Mon, Nov 1, 2021 at 11:22 AM Muchun Song <songmuchun@...edance.com> wrote:
>
> This series can minimize the overhead of struct page for 2MB HugeTLB pages
> significantly. It further reduces the overhead of struct page by 12.5% for
> a 2MB HugeTLB compared to the previous approach, which means 2GB per 1TB
> HugeTLB. It is a nice gain. Comments and reviews are welcome. Thanks.
>
Hi,
Ping guys. Does anyone have any comments or suggestions
on this series?
Thanks.
Powered by blists - more mailing lists