linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Alistair Popple <apopple@nvidia.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	 alison.schofield@intel.com, lina@asahilina.net,
	zhang.lyra@gmail.com,  gerald.schaefer@linux.ibm.com,
	vishal.l.verma@intel.com, dave.jiang@intel.com,
	 logang@deltatee.com, bhelgaas@google.com, jack@suse.cz,
	jgg@ziepe.ca,  catalin.marinas@arm.com, will@kernel.org,
	mpe@ellerman.id.au, npiggin@gmail.com,
	 dave.hansen@linux.intel.com, ira.weiny@intel.com,
	willy@infradead.org, djwong@kernel.org,  tytso@mit.edu,
	linmiaohe@huawei.com, david@redhat.com, peterx@redhat.com,
	 linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	 linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, nvdimm@lists.linux.dev,
	 linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-ext4@vger.kernel.org,  linux-xfs@vger.kernel.org,
	jhubbard@nvidia.com, hch@lst.de, david@fromorbit.com,
	 chenhuacai@kernel.org, kernel@xen0n.name,
	loongarch@lists.linux.dev
Subject: Re: [PATCH v6 22/26] device/dax: Properly refcount device dax pages when mapping
Date: Mon, 3 Feb 2025 22:29:00 +1100	[thread overview]
Message-ID: <7tmxffcwudefbm7bva4y54bnyp2le2fvtqkmm2ofdhyjvgjqly@4tkut3oxgjvh> (raw)
In-Reply-To: <67860059b200b_20fa294b5@dwillia2-xfh.jf.intel.com.notmuch>

On Mon, Jan 13, 2025 at 10:12:41PM -0800, Dan Williams wrote:
> Alistair Popple wrote:
> > Device DAX pages are currently not reference counted when mapped,
> > instead relying on the devmap PTE bit to ensure mapping code will not
> > get/put references. This requires special handling in various page
> > table walkers, particularly GUP, to manage references on the
> > underlying pgmap to ensure the pages remain valid.
> > 
> > However there is no reason these pages can't be refcounted properly at
> > map time. Doning so eliminates the need for the devmap PTE bit,
> > freeing up a precious PTE bit. It also simplifies GUP as it no longer
> > needs to manage the special pgmap references and can instead just
> > treat the pages normally as defined by vm_normal_page().
> > 
> > Signed-off-by: Alistair Popple <apopple@nvidia.com>
> > ---
> >  drivers/dax/device.c | 15 +++++++++------
> >  mm/memremap.c        | 13 ++++++-------
> >  2 files changed, 15 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/dax/device.c b/drivers/dax/device.c
> > index 6d74e62..fd22dbf 100644
> > --- a/drivers/dax/device.c
> > +++ b/drivers/dax/device.c
> > @@ -126,11 +126,12 @@ static vm_fault_t __dev_dax_pte_fault(struct dev_dax *dev_dax,
> >  		return VM_FAULT_SIGBUS;
> >  	}
> >  
> > -	pfn = phys_to_pfn_t(phys, PFN_DEV|PFN_MAP);
> > +	pfn = phys_to_pfn_t(phys, 0);
> >  
> >  	dax_set_mapping(vmf, pfn, fault_size);
> >  
> > -	return vmf_insert_mixed(vmf->vma, vmf->address, pfn);
> > +	return vmf_insert_page_mkwrite(vmf, pfn_t_to_page(pfn),
> > +					vmf->flags & FAULT_FLAG_WRITE);
> >  }
> >  
> >  static vm_fault_t __dev_dax_pmd_fault(struct dev_dax *dev_dax,
> > @@ -169,11 +170,12 @@ static vm_fault_t __dev_dax_pmd_fault(struct dev_dax *dev_dax,
> >  		return VM_FAULT_SIGBUS;
> >  	}
> >  
> > -	pfn = phys_to_pfn_t(phys, PFN_DEV|PFN_MAP);
> > +	pfn = phys_to_pfn_t(phys, 0);
> >  
> >  	dax_set_mapping(vmf, pfn, fault_size);
> >  
> > -	return vmf_insert_pfn_pmd(vmf, pfn, vmf->flags & FAULT_FLAG_WRITE);
> > +	return vmf_insert_folio_pmd(vmf, page_folio(pfn_t_to_page(pfn)),
> > +				vmf->flags & FAULT_FLAG_WRITE);
> 
> This looks suspect without initializing the compound page metadata.

I initially wondered about this too, however I think the compound page metadata
should be initialised by memmap_init_zone_device(). That said I kind of get lost
in all the namespace/CXL/PMEM/DAX drivers in the stack so maybe I've overlooked
something.
 
> This might be getting compound pages by default with
> CONFIG_ARCH_WANT_OPTIMIZE_DAX_VMEMMAP. The device-dax unit tests are ok
> so far, but that is not super comforting until I can think about this a
> bit more... but not tonight.

From my reading of the code I don't _think_
CONFIG_ARCH_WANT_OPTIMIZE_DAX_VMEMMAP would change whether or not we got
compound pages by default, just that if we did some of the (tail?) pages may
refer to the same physical struct page.

> Might as well fix up device-dax refcounts in this series too, but I
> won't ask you to do that, will send you something to include.

Eh. That should be relatively straight forward. But then I thought that about FS
DAX too :-)


  reply	other threads:[~2025-02-03 11:29 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-10  6:00 [PATCH v6 00/26] fs/dax: Fix ZONE_DEVICE page reference counts Alistair Popple
2025-01-10  6:00 ` [PATCH v6 01/26] fuse: Fix dax truncate/punch_hole fault path Alistair Popple
2025-02-05 13:03   ` Vivek Goyal
2025-02-06  0:10     ` Dan Williams
2025-02-06 12:41       ` Asahi Lina
2025-02-06 19:44         ` Dan Williams
2025-02-06 19:57           ` Asahi Lina
2025-02-06 13:37       ` Vivek Goyal
2025-02-06 14:30         ` Stefan Hajnoczi
2025-02-06 14:59           ` Albert Esteve
2025-02-06 18:10             ` Stefan Hajnoczi
2025-02-06 18:22             ` David Hildenbrand
2025-02-07 16:16               ` Albert Esteve
2025-01-10  6:00 ` [PATCH v6 02/26] fs/dax: Return unmapped busy pages from dax_layout_busy_page_range() Alistair Popple
2025-01-10  6:00 ` [PATCH v6 03/26] fs/dax: Don't skip locked entries when scanning entries Alistair Popple
2025-01-10  6:00 ` [PATCH v6 04/26] fs/dax: Refactor wait for dax idle page Alistair Popple
2025-01-10  6:00 ` [PATCH v6 05/26] fs/dax: Create a common implementation to break DAX layouts Alistair Popple
2025-01-10 16:44   ` Darrick J. Wong
2025-01-13  0:47     ` Alistair Popple
2025-01-13  2:47       ` Darrick J. Wong
2025-01-13 20:11   ` Dan Williams
2025-01-13 23:06   ` Dan Williams
2025-01-14  0:19   ` Dan Williams
2025-01-10  6:00 ` [PATCH v6 06/26] fs/dax: Always remove DAX page-cache entries when breaking layouts Alistair Popple
2025-01-13 23:31   ` Dan Williams
2025-01-10  6:00 ` [PATCH v6 07/26] fs/dax: Ensure all pages are idle prior to filesystem unmount Alistair Popple
2025-01-10 16:50   ` Darrick J. Wong
2025-01-13  0:57     ` Alistair Popple
2025-01-13  2:49       ` Darrick J. Wong
2025-01-13  5:48         ` Alistair Popple
2025-01-13 16:39           ` Darrick J. Wong
2025-01-13 23:42   ` Dan Williams
2025-01-10  6:00 ` [PATCH v6 08/26] fs/dax: Remove PAGE_MAPPING_DAX_SHARED mapping flag Alistair Popple
2025-01-14  0:52   ` Dan Williams
2025-01-15  5:32     ` Alistair Popple
2025-01-15  5:44       ` Dan Williams
2025-01-17  0:54         ` Alistair Popple
2025-01-14 14:47   ` David Hildenbrand
2025-01-10  6:00 ` [PATCH v6 09/26] mm/gup: Remove redundant check for PCI P2PDMA page Alistair Popple
2025-01-10  6:00 ` [PATCH v6 10/26] mm/mm_init: Move p2pdma page refcount initialisation to p2pdma Alistair Popple
2025-01-14 14:51   ` David Hildenbrand
2025-01-10  6:00 ` [PATCH v6 11/26] mm: Allow compound zone device pages Alistair Popple
2025-01-14 14:59   ` David Hildenbrand
2025-01-17  1:05     ` Alistair Popple
2025-01-10  6:00 ` [PATCH v6 12/26] mm/memory: Enhance insert_page_into_pte_locked() to create writable mappings Alistair Popple
2025-01-14 15:03   ` David Hildenbrand
     [not found]   ` <6785b90f300d8_20fa29465@dwillia2-xfh.jf.intel.com.notmuch>
2025-01-15  5:36     ` Alistair Popple
2025-01-10  6:00 ` [PATCH v6 13/26] mm/memory: Add vmf_insert_page_mkwrite() Alistair Popple
2025-01-14 16:15   ` David Hildenbrand
2025-01-15  6:13     ` Alistair Popple
2025-01-10  6:00 ` [PATCH v6 14/26] rmap: Add support for PUD sized mappings to rmap Alistair Popple
2025-01-14  1:21   ` Dan Williams
2025-01-10  6:00 ` [PATCH v6 15/26] huge_memory: Add vmf_insert_folio_pud() Alistair Popple
2025-01-14  1:27   ` Dan Williams
2025-01-14 16:22   ` David Hildenbrand
2025-01-15  6:38     ` Alistair Popple
2025-01-10  6:00 ` [PATCH v6 16/26] huge_memory: Add vmf_insert_folio_pmd() Alistair Popple
2025-01-14  2:04   ` Dan Williams
2025-01-14 16:40   ` David Hildenbrand
2025-01-14 17:22     ` Dan Williams
2025-01-15  7:05       ` Alistair Popple
2025-01-10  6:00 ` [PATCH v6 17/26] memremap: Add is_devdax_page() and is_fsdax_page() helpers Alistair Popple
2025-01-14  2:05   ` Dan Williams
2025-01-10  6:00 ` [PATCH v6 18/26] mm/gup: Don't allow FOLL_LONGTERM pinning of FS DAX pages Alistair Popple
2025-01-14  2:16   ` Dan Williams
2025-01-10  6:00 ` [PATCH v6 19/26] proc/task_mmu: Mark devdax and fsdax pages as always unpinned Alistair Popple
2025-01-14  2:28   ` Dan Williams
2025-01-14 16:45     ` David Hildenbrand
2025-01-17  1:28       ` Alistair Popple
2025-01-10  6:00 ` [PATCH v6 20/26] mm/mlock: Skip ZONE_DEVICE PMDs during mlock Alistair Popple
2025-01-14  2:42   ` Dan Williams
2025-01-17  1:54     ` Alistair Popple
2025-01-10  6:00 ` [PATCH v6 21/26] fs/dax: Properly refcount fs dax pages Alistair Popple
2025-01-10 16:54   ` Darrick J. Wong
2025-01-13  3:18     ` Alistair Popple
2025-01-14  3:35   ` Dan Williams
2025-02-07  5:31     ` Alistair Popple
2025-02-07  5:50       ` Dan Williams
2025-02-09 23:35         ` Alistair Popple
2025-01-10  6:00 ` [PATCH v6 22/26] device/dax: Properly refcount device dax pages when mapping Alistair Popple
2025-01-14  6:12   ` Dan Williams
2025-02-03 11:29     ` Alistair Popple [this message]
2025-01-10  6:00 ` [PATCH v6 23/26] mm: Remove pXX_devmap callers Alistair Popple
2025-01-14 18:50   ` Dan Williams
2025-01-15  7:27     ` Alistair Popple
2025-02-04 19:06       ` Dan Williams
2025-02-05  9:57         ` Alistair Popple
2025-01-10  6:00 ` [PATCH v6 24/26] mm: Remove devmap related functions and page table bits Alistair Popple
2025-01-11 10:08   ` Huacai Chen
2025-01-14 19:03   ` Dan Williams
2025-01-10  6:00 ` [PATCH v6 25/26] Revert "riscv: mm: Add support for ZONE_DEVICE" Alistair Popple
2025-01-14 19:11   ` Dan Williams
2025-01-10  6:00 ` [PATCH v6 26/26] Revert "LoongArch: Add ARCH_HAS_PTE_DEVMAP support" Alistair Popple
2025-01-10  7:05 ` [PATCH v6 00/26] fs/dax: Fix ZONE_DEVICE page reference counts Dan Williams
2025-01-11  1:30   ` Andrew Morton
2025-01-11  3:35     ` Dan Williams
2025-01-13  1:05       ` Alistair Popple

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=7tmxffcwudefbm7bva4y54bnyp2le2fvtqkmm2ofdhyjvgjqly@4tkut3oxgjvh \
    --to=apopple@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=alison.schofield@intel.com \
    --cc=bhelgaas@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=chenhuacai@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dave.jiang@intel.com \
    --cc=david@fromorbit.com \
    --cc=david@redhat.com \
    --cc=djwong@kernel.org \
    --cc=gerald.schaefer@linux.ibm.com \
    --cc=hch@lst.de \
    --cc=ira.weiny@intel.com \
    --cc=jack@suse.cz \
    --cc=jgg@ziepe.ca \
    --cc=jhubbard@nvidia.com \
    --cc=kernel@xen0n.name \
    --cc=lina@asahilina.net \
    --cc=linmiaohe@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=logang@deltatee.com \
    --cc=loongarch@lists.linux.dev \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=nvdimm@lists.linux.dev \
    --cc=peterx@redhat.com \
    --cc=tytso@mit.edu \
    --cc=vishal.l.verma@intel.com \
    --cc=will@kernel.org \
    --cc=willy@infradead.org \
    --cc=zhang.lyra@gmail.com \
    /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