linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Joao Martins <joao.m.martins@oracle.com>
Cc: linux-mm@kvack.org, Dan Williams <dan.j.williams@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Matthew Wilcox <willy@infradead.org>,
	Jason Gunthorpe <jgg@ziepe.ca>, Jane Chu <jane.chu@oracle.com>,
	Muchun Song <songmuchun@bytedance.com>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Jonathan Corbet <corbet@lwn.net>, Christoph Hellwig <hch@lst.de>,
	nvdimm@lists.linux.dev, linux-doc@vger.kernel.org
Subject: Re: [PATCH v9 4/5] mm/sparse-vmemmap: improve memory savings for compound devmaps
Date: Wed, 20 Apr 2022 14:40:36 -0700	[thread overview]
Message-ID: <20220420144036.0bd0955e5d8478ca64f2df19@linux-foundation.org> (raw)
In-Reply-To: <20220420155310.9712-5-joao.m.martins@oracle.com>

On Wed, 20 Apr 2022 16:53:09 +0100 Joao Martins <joao.m.martins@oracle.com> wrote:

> A compound devmap is a dev_pagemap with @vmemmap_shift > 0 and it
> means that pages are mapped at a given huge page alignment and utilize
> uses compound pages as opposed to order-0 pages.
> 
> Take advantage of the fact that most tail pages look the same (except
> the first two) to minimize struct page overhead. Allocate a separate
> page for the vmemmap area which contains the head page and separate for
> the next 64 pages. The rest of the subsections then reuse this tail
> vmemmap page to initialize the rest of the tail pages.
> 
> Sections are arch-dependent (e.g. on x86 it's 64M, 128M or 512M) and
> when initializing compound devmap with big enough @vmemmap_shift (e.g.
> 1G PUD) it may cross multiple sections. The vmemmap code needs to
> consult @pgmap so that multiple sections that all map the same tail
> data can refer back to the first copy of that data for a given
> gigantic page.
> 
> On compound devmaps with 2M align, this mechanism lets 6 pages be
> saved out of the 8 necessary PFNs necessary to set the subsection's
> 512 struct pages being mapped. On a 1G compound devmap it saves
> 4094 pages.
> 
> Altmap isn't supported yet, given various restrictions in altmap pfn
> allocator, thus fallback to the already in use vmemmap_populate().  It
> is worth noting that altmap for devmap mappings was there to relieve the
> pressure of inordinate amounts of memmap space to map terabytes of pmem.
> With compound pages the motivation for altmaps for pmem gets reduced.
> 
> ...
>
> @@ -665,12 +770,19 @@ struct page * __meminit __populate_section_memmap(unsigned long pfn,
>  {
>  	unsigned long start = (unsigned long) pfn_to_page(pfn);
>  	unsigned long end = start + nr_pages * sizeof(struct page);
> +	int r;
>  
>  	if (WARN_ON_ONCE(!IS_ALIGNED(pfn, PAGES_PER_SUBSECTION) ||
>  		!IS_ALIGNED(nr_pages, PAGES_PER_SUBSECTION)))
>  		return NULL;
>  
> -	if (vmemmap_populate(start, end, nid, altmap))
> +	if (is_power_of_2(sizeof(struct page)) &&

Note that Muchun is working on a compile-time
STRUCT_PAGE_SIZE_IS_POWER_OF_2 which this site should be able to
utilize.

https://lkml.kernel.org/r/20220413144748.84106-2-songmuchun@bytedance.com

> +	    pgmap && pgmap_vmemmap_nr(pgmap) > 1 && !altmap)
> +		r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap);
> +	else
> +		r = vmemmap_populate(start, end, nid, altmap);
> +
> +	if (r < 0)
>  		return NULL;
>  
>  	return pfn_to_page(pfn);



  reply	other threads:[~2022-04-20 21:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20 15:53 [PATCH v9 0/5] sparse-vmemmap: memory savings for compound devmaps (device-dax) Joao Martins
2022-04-20 15:53 ` [PATCH v9 1/5] mm/sparse-vmemmap: add a pgmap argument to section activation Joao Martins
2022-04-20 15:53 ` [PATCH v9 2/5] mm/sparse-vmemmap: refactor core of vmemmap_populate_basepages() to helper Joao Martins
2022-04-20 15:53 ` [PATCH v9 3/5] mm/hugetlb_vmemmap: move comment block to Documentation/vm Joao Martins
2022-04-20 15:53 ` [PATCH v9 4/5] mm/sparse-vmemmap: improve memory savings for compound devmaps Joao Martins
2022-04-20 21:40   ` Andrew Morton [this message]
2022-04-20 15:53 ` [PATCH v9 5/5] mm/page_alloc: reuse tail struct pages " Joao Martins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220420144036.0bd0955e5d8478ca64f2df19@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=dan.j.williams@intel.com \
    --cc=hch@lst.de \
    --cc=jane.chu@oracle.com \
    --cc=jgg@ziepe.ca \
    --cc=joao.m.martins@oracle.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=nvdimm@lists.linux.dev \
    --cc=songmuchun@bytedance.com \
    --cc=vishal.l.verma@intel.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox