On Fri 30-10-20 18:24:25, Muchun Song wrote:
> On Fri, Oct 30, 2020 at 5:14 PM Michal Hocko wrote:
> >
> > On Mon 26-10-20 22:50:55, Muchun Song wrote:
> > > If we uses the 1G hugetlbpage, we can save 4095 pages. This is a very
> > > substantial gain. On our server, run some SPDK/QEMU
On Fri, Oct 30, 2020 at 5:14 PM Michal Hocko wrote:
>
> On Mon 26-10-20 22:50:55, Muchun Song wrote:
> > If we uses the 1G hugetlbpage, we can save 4095 pages. This is a very
> > substantial gain. On our server, run some SPDK/QEMU applications which
> > will use 1000GB hugetlbpage. With this
On Mon 26-10-20 22:50:55, Muchun Song wrote:
> If we uses the 1G hugetlbpage, we can save 4095 pages. This is a very
> substantial gain. On our server, run some SPDK/QEMU applications which
> will use 1000GB hugetlbpage. With this feature enabled, we can save
> ~16GB(1G hugepage)/~11GB(2MB
On Mon, Oct 26, 2020 at 11:53 PM Matthew Wilcox wrote:
>
> On Mon, Oct 26, 2020 at 10:50:55PM +0800, Muchun Song wrote:
> > For tail pages, the value of compound_dtor is the same. So we can reuse
>
> compound_dtor is only set on the first tail page. compound_head is
> what you mean here, I
On Mon, Oct 26, 2020 at 10:50:55PM +0800, Muchun Song wrote:
> For tail pages, the value of compound_dtor is the same. So we can reuse
compound_dtor is only set on the first tail page. compound_head is
what you mean here, I think.
Hi all,
This patch series will free some vmemmap pages(struct page structures)
associated with each hugetlbpage when preallocated to save memory.
Nowadays we track the status of physical page frames using `struct page`
arranged in one or more arrays. And here exists one-to-one mapping between
6 matches
Mail list logo
