[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201217145953.GA13874@linux>
Date: Thu, 17 Dec 2020 15:59:58 +0100
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, mchehab+huawei@...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, duanxiongchun@...edance.com,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v10 00/11] Free some vmemmap pages of HugeTLB page
On Thu, Dec 17, 2020 at 08:12:52PM +0800, Muchun Song wrote:
> In this case, for the 1GB HugeTLB page, we can save 4088 pages(There are
> 4096 pages for struct page structs, we reserve 2 pages for vmemmap and 8
> pages for page tables. So we can save 4088 pages). This is a very substantial
> gain. On our server, run some SPDK/QEMU applications which will use 1024GB
> hugetlbpage. With this feature enabled, we can save ~16GB(1G hugepage)/~11GB
> (2MB hugepage, the worst case is 10GB while the best is 12GB) memory.
Is the above really true?
We no longer need to allocate pagetables, so the savings go up to 4094, right?
I will be off for a few days but I expect to get back to this and review the
missing bits when I am back.
--
Oscar Salvador
SUSE L3
Powered by blists - more mailing lists