From: Christoph Hellwig <hch@lst.de>
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>,
Dave Jiang <dave.jiang@intel.com>,
Naoya Horiguchi <naoya.horiguchi@nec.com>,
Matthew Wilcox <willy@infradead.org>,
Jason Gunthorpe <jgg@ziepe.ca>,
John Hubbard <jhubbard@nvidia.com>,
Jane Chu <jane.chu@oracle.com>,
Muchun Song <songmuchun@bytedance.com>,
Mike Kravetz <mike.kravetz@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jonathan Corbet <corbet@lwn.net>, Christoph Hellwig <hch@lst.de>,
nvdimm@lists.linux.dev, linux-doc@vger.kernel.org
Subject: Re: [PATCH v5 8/8] device-dax: compound devmap support
Date: Wed, 17 Nov 2021 10:43:08 +0100 [thread overview]
Message-ID: <20211117094308.GC8429@lst.de> (raw)
In-Reply-To: <20211112150824.11028-9-joao.m.martins@oracle.com>
On Fri, Nov 12, 2021 at 04:08:24PM +0100, Joao Martins wrote:
> Use the newly added compound devmap facility which maps the assigned dax
> ranges as compound pages at a page size of @align.
>
> dax devices are created with a fixed @align (huge page size) which is
> enforced through as well at mmap() of the device. Faults, consequently
> happen too at the specified @align specified at the creation, and those
> don't change throughout dax device lifetime. MCEs unmap a whole dax
> huge page, as well as splits occurring at the configured page size.
>
> Performance measured by gup_test improves considerably for
> unpin_user_pages() and altmap with NVDIMMs:
>
> $ gup_test -f /dev/dax1.0 -m 16384 -r 10 -S -a -n 512 -w
> (pin_user_pages_fast 2M pages) put:~71 ms -> put:~22 ms
> [altmap]
> (pin_user_pages_fast 2M pages) get:~524ms put:~525 ms -> get: ~127ms put:~71ms
>
> $ gup_test -f /dev/dax1.0 -m 129022 -r 10 -S -a -n 512 -w
> (pin_user_pages_fast 2M pages) put:~513 ms -> put:~188 ms
> [altmap with -m 127004]
> (pin_user_pages_fast 2M pages) get:~4.1 secs put:~4.12 secs -> get:~1sec put:~563ms
>
> .. as well as unpin_user_page_range_dirty_lock() being just as effective
> as THP/hugetlb[0] pages.
>
> [0] https://lore.kernel.org/linux-mm/20210212130843.13865-5-joao.m.martins@oracle.com/
>
> Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> ---
> drivers/dax/device.c | 57 ++++++++++++++++++++++++++++++++++----------
> 1 file changed, 44 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/dax/device.c b/drivers/dax/device.c
> index a65c67ab5ee0..0c2ac97d397d 100644
> --- a/drivers/dax/device.c
> +++ b/drivers/dax/device.c
> @@ -192,6 +192,42 @@ static vm_fault_t __dev_dax_pud_fault(struct dev_dax *dev_dax,
> }
> #endif /* !CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD */
>
> +static void set_page_mapping(struct vm_fault *vmf, pfn_t pfn,
> + unsigned long fault_size,
> + struct address_space *f_mapping)
> +{
> + unsigned long i;
> + pgoff_t pgoff;
> +
> + pgoff = linear_page_index(vmf->vma, ALIGN(vmf->address, fault_size));
> +
> + for (i = 0; i < fault_size / PAGE_SIZE; i++) {
> + struct page *page;
> +
> + page = pfn_to_page(pfn_t_to_pfn(pfn) + i);
> + if (page->mapping)
> + continue;
> + page->mapping = f_mapping;
> + page->index = pgoff + i;
> + }
> +}
No need to pass f_mapping here, it must be vmf->vma->vm_file->f_mapping.
> +static void set_compound_mapping(struct vm_fault *vmf, pfn_t pfn,
> + unsigned long fault_size,
> + struct address_space *f_mapping)
> +{
> + struct page *head;
> +
> + head = pfn_to_page(pfn_t_to_pfn(pfn));
> + head = compound_head(head);
> + if (head->mapping)
> + return;
> +
> + head->mapping = f_mapping;
> + head->index = linear_page_index(vmf->vma,
> + ALIGN(vmf->address, fault_size));
> +}
Same here.
> if (rc == VM_FAULT_NOPAGE) {
> - unsigned long i;
> - pgoff_t pgoff;
> + struct dev_pagemap *pgmap = dev_dax->pgmap;
If you're touching this anyway: why not do an early return here for
the error case to simplify the flow?
next prev parent reply other threads:[~2021-11-17 9:43 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-12 15:08 [PATCH v5 0/8] mm, dax: Introduce compound pages in devmap Joao Martins
2021-11-12 15:08 ` [PATCH v5 1/8] memory-failure: fetch compound_head after pgmap_pfn_valid() Joao Martins
2021-11-12 15:08 ` [PATCH v5 2/8] mm/page_alloc: split prep_compound_page into head and tail subparts Joao Martins
2021-11-12 15:08 ` [PATCH v5 3/8] mm/page_alloc: refactor memmap_init_zone_device() page init Joao Martins
2021-11-12 15:08 ` [PATCH v5 4/8] mm/memremap: add ZONE_DEVICE support for compound pages Joao Martins
2021-11-12 15:08 ` [PATCH v5 5/8] device-dax: use ALIGN() for determining pgoff Joao Martins
2021-11-12 15:08 ` [PATCH v5 6/8] device-dax: use struct_size() Joao Martins
2021-11-17 9:37 ` Christoph Hellwig
2021-11-17 10:15 ` Joao Martins
2021-11-12 15:08 ` [PATCH v5 7/8] device-dax: ensure dev_dax->pgmap is valid for dynamic devices Joao Martins
2021-11-17 9:37 ` Christoph Hellwig
2021-11-17 10:15 ` Joao Martins
2021-11-12 15:08 ` [PATCH v5 8/8] device-dax: compound devmap support Joao Martins
2021-11-12 15:34 ` Jason Gunthorpe
2021-11-15 12:11 ` Joao Martins
2021-11-15 16:49 ` Jason Gunthorpe
2021-11-16 16:38 ` Joao Martins
2021-11-19 16:12 ` Joao Martins
2021-11-19 16:55 ` Jason Gunthorpe
2021-11-19 19:26 ` Joao Martins
2021-11-19 19:53 ` Jason Gunthorpe
2021-11-19 20:13 ` Joao Martins
2021-11-17 9:43 ` Christoph Hellwig [this message]
2021-11-17 10:22 ` Joao Martins
2021-11-12 15:40 ` [PATCH v5 0/8] mm, dax: Introduce compound pages in devmap Jason Gunthorpe
2021-11-15 11:00 ` Joao Martins
-- strict thread matches above, loose matches on Subject: below --
2021-11-15 18:43 [PATCH v5 8/8] device-dax: compound devmap support kernel test robot
2021-11-15 18:43 ` kernel test robot
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=20211117094308.GC8429@lst.de \
--to=hch@lst.de \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=jane.chu@oracle.com \
--cc=jgg@ziepe.ca \
--cc=jhubbard@nvidia.com \
--cc=joao.m.martins@oracle.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=naoya.horiguchi@nec.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.