On 8/27/21 5:25 PM, Jason Gunthorpe wrote:
> On Fri, Aug 27, 2021 at 03:58:13PM +0100, Joao Martins wrote:
>
>> #if defined(CONFIG_ARCH_HAS_PTE_DEVMAP) &&
>> defined(CONFIG_TRANSPARENT_HUGEPAGE)
>> static int __gup_device_huge(unsigned long pfn, unsigned long addr,
>>
On Fri, Aug 27, 2021 at 03:58:13PM +0100, Joao Martins wrote:
> #if defined(CONFIG_ARCH_HAS_PTE_DEVMAP) &&
> defined(CONFIG_TRANSPARENT_HUGEPAGE)
> static int __gup_device_huge(unsigned long pfn, unsigned long addr,
>unsigned long end, unsigned int flags,
>
On 8/27/21 4:33 PM, Christoph Hellwig wrote:
> On Fri, Aug 27, 2021 at 03:58:09PM +0100, Joao Martins wrote:
>> + * @geometry: structural definition of how the vmemmap metadata is
>> populated.
>> + * A zero or 1 defaults to using base pages as the memmap metadata
>> + * representation. A bigger
On Fri, Aug 27, 2021 at 03:58:09PM +0100, Joao Martins wrote:
> + * @geometry: structural definition of how the vmemmap metadata is populated.
> + * A zero or 1 defaults to using base pages as the memmap metadata
> + * representation. A bigger value will set up compound struct pages
> + * rep
Right now, only static dax regions have a valid @pgmap pointer in its
struct dev_dax. Dynamic dax case however, do not.
In preparation for device-dax compound devmap support, make sure that
dev_dax pgmap field is set after it has been allocated and initialized.
dynamic dax device have the @pgmap
Currently, for compound PUD mappings, the implementation consumes 40MB
per TB but it can be optimized to 16MB per TB with the approach
detailed below.
Right now basepages are used to populate the PUD tail pages, and it
picks the address of the previous page of the subsection that precedes
the memm
Currently memmap_init_zone_device() ends up initializing 32768 pages
when it only needs to initialize 128 given tail page reuse. That
number is worse with 1GB compound page geometries, 262144 instead of
128. Update memmap_init_zone_device() to skip redundant
initialization, detailed below.
When a
A compound devmap is a dev_pagemap with @geometry > PAGE_SIZE 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
In preparation for device-dax for using hugetlbfs compound page tail
deduplication technique, move the comment block explanation into a
common place in Documentation/vm.
Cc: Muchun Song
Cc: Mike Kravetz
Suggested-by: Dan Williams
Signed-off-by: Joao Martins
Reviewed-by: Muchun Song
Reviewed-b
Add a new @geometry property for struct dev_pagemap which specifies that a
devmap is composed of a set of compound pages of size @geometry, instead of
base pages. When a compound page geometry is requested, all but the first
page are initialised as tail pages instead of order-0 pages.
For certain
Rather than calculating @pgoff manually, switch to ALIGN() instead.
Suggested-by: Dan Williams
Signed-off-by: Joao Martins
Reviewed-by: Dan Williams
---
drivers/dax/device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dax/device.c b/drivers/dax/device.c
inde
Use the newly added compound devmap facility which maps the assigned dax
ranges as compound pages at a page size of @align. Currently, this means,
that region/namespace bootstrap would take considerably less, given that
you would initialize considerably less pages.
On setups with 128G NVDIMMs the
Use try_grab_compound_head() for device-dax GUP when configured with a
compound devmap.
Rather than incrementing the refcount for each page, do one atomic
addition for all the pages to be pinned.
Performance measured by gup_benchmark improves considerably
get_user_pages_fast() and pin_user_pages_
dress it and that is also applicable to
THP. But will submit that as a follow up of this.
Patches apply on top of linux-next tag next-20210827 (commit 5e63226c7228).
Comments and suggestions very much appreciated!
Older Changelog,
v2 -> v3[3]:
* Collect Mike's Ack on patch 2 (Mike)
In support of using compound pages for devmap mappings, plumb the pgmap
down to the vmemmap_populate implementation. Note that while altmap is
retrievable from pgmap the memory hotplug code passes altmap without
pgmap[*], so both need to be independently plumbed.
So in addition to @altmap, pass @p
Move struct page init to an helper function __init_zone_device_page().
This is in preparation for sharing the storage for / deduplicating
compound page metadata.
Signed-off-by: Joao Martins
Reviewed-by: Dan Williams
---
mm/page_alloc.c | 74 +++--
1
In preparation for describing a memmap with compound pages, move the
actual pte population logic into a separate function
vmemmap_populate_address() and have vmemmap_populate_basepages() walk
through all base pages it needs to populate.
Signed-off-by: Joao Martins
---
mm/sparse-vmemmap.c | 51 ++
Split the utility function prep_compound_page() into head and tail
counterparts, and use them accordingly.
This is in preparation for sharing the storage for / deduplicating
compound page metadata.
Signed-off-by: Joao Martins
Acked-by: Mike Kravetz
Reviewed-by: Dan Williams
Reviewed-by: Muchun
memory_failure_dev_pagemap() at the moment assumes base pages (e.g.
dax_lock_page()). For devmap with compound pages fetch the
compound_head in case a tail page memory failure is being handled.
Currently this is a nop, but in the advent of compound pages in
dev_pagemap it allows memory_failure_de
19 matches
Mail list logo
