Linux-Fsdevel Archive mirror
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Alistair Popple <apopple@nvidia.com>,
	Dan Williams <dan.j.williams@intel.com>
Cc: <linux-mm@kvack.org>, <david@fromorbit.com>,
	<jhubbard@nvidia.com>, <rcampbell@nvidia.com>,
	<willy@infradead.org>, <jgg@nvidia.com>,
	<linux-fsdevel@vger.kernel.org>, <jack@suse.cz>,
	<djwong@kernel.org>, <hch@lst.de>, <david@redhat.com>,
	<ruansy.fnst@fujitsu.com>, <nvdimm@lists.linux.dev>,
	<linux-xfs@vger.kernel.org>, <linux-ext4@vger.kernel.org>,
	<jglisse@redhat.com>
Subject: Re: [RFC 04/10] fs/dax: Don't track page mapping/index
Date: Mon, 15 Apr 2024 13:51:33 -0700	[thread overview]
Message-ID: <661d9355239bc_4d56129485@dwillia2-mobl3.amr.corp.intel.com.notmuch> (raw)
In-Reply-To: <878r1f2jko.fsf@nvdebian.thelocal>

Alistair Popple wrote:
> I was initially concerned about these cases because I was wondering if
> folio subpages could ever get different mappings and the shared case
> implied they could. But it seems that's xfs specific and there is a
> separate mechanism to deal with looking up ->mapping/index for that. So
> I guess we should still be able to safely store this on the folio
> head. I will double check and update this change.
> 

I think there is path to store this information only on the folio head.
However, ugh, I think this is potentially another "head" of the
pmd_devmap() hydra.

pmd_devmap() taught the core-mm to treat dax_pmds indentically to
thp_pmds *except* for the __split_huge_pmd() case:

   5c7fb56e5e3f mm, dax: dax-pmd vs thp-pmd vs hugetlbfs-pmd

Later on pmd migration entries joined pmd_devmap() in skipping splits:

   84c3fc4e9c56 mm: thp: check pmd migration entry in common path

Unfortunately, pmd_devmap() stopped being considered for skipping
splits here:

   7f7609175ff2 mm/huge_memory: remove stale locking logic from __split_huge_pmd()

Likely __split_huge_pmd_locked() grew support for pmd migration handling
and forgot about the pmd_devmap() case.

So now Linux has been allowing FSDAX pmd splits since v5.18... but with
no reports of any issues. Likely this is benefiting from the fact that
the preconditions for splitting are rarely if ever satisfied because
FSDAX mappings are never anon, and establishing the mapping in the first
place requires a 2MB aligned file extent and that is likely never
fractured.

Same for device-dax where the fracturing *should* not be allowed, but I
will feel better with focus tests to go after mremap() cases that would
attempt to split the page.

  reply	other threads:[~2024-04-15 20:51 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-11  0:57 [RFC 00/10] fs/dax: Fix FS DAX page reference counts Alistair Popple
2024-04-11  0:57 ` [RFC 01/10] mm/gup.c: Remove redundant check for PCI P2PDMA page Alistair Popple
2024-04-11 12:59   ` Jason Gunthorpe
2024-04-11 13:47   ` David Hildenbrand
2024-04-12  1:37     ` Alistair Popple
2024-04-11  0:57 ` [RFC 02/10] mm/hmm: Remove dead check for HugeTLB and FS DAX Alistair Popple
2024-04-11 12:25   ` Jason Gunthorpe
2024-04-11 13:37     ` Peter Xu
2024-04-12  1:28       ` Alistair Popple
2024-04-11  0:57 ` [RFC 03/10] pci/p2pdma: Don't initialise page refcount to one Alistair Popple
2024-04-11 12:29   ` Jason Gunthorpe
2024-04-12  5:40     ` Alistair Popple
2024-04-12 17:20   ` Dan Williams
2024-05-09 21:59   ` Logan Gunthorpe
2024-05-09 23:14     ` Alistair Popple
2024-04-11  0:57 ` [RFC 04/10] fs/dax: Don't track page mapping/index Alistair Popple
2024-04-12 15:22   ` Jan Kara
2024-04-12 17:31     ` Dan Williams
2024-04-15  7:03       ` Alistair Popple
2024-04-15 20:51         ` Dan Williams [this message]
2024-04-16  0:07           ` Alistair Popple
2024-04-16  0:36             ` Dan Williams
2024-04-12 17:21   ` Dan Williams
2024-04-11  0:57 ` [RFC 05/10] fs/dax: Refactor wait for dax idle page Alistair Popple
2024-04-12 14:37   ` Jan Kara
2024-04-13 20:19   ` John Hubbard
2024-04-15  8:41     ` Alistair Popple
2024-04-11  0:57 ` [RFC 06/10] fs/dax: Add dax_page_free callback Alistair Popple
2024-04-11  0:57 ` [RFC 07/10] mm: Allow compound zone device pages Alistair Popple
2024-04-11 12:32   ` Jason Gunthorpe
2024-04-11 14:10   ` Matthew Wilcox
2024-04-12  1:38     ` Alistair Popple
2024-04-11  0:57 ` [RFC 08/10] fs/dax: Properly refcount fs dax pages Alistair Popple
2024-04-11  0:57 ` [RFC 09/10] mm/khugepage.c: Warn if trying to scan devmap pmd Alistair Popple
2024-04-11 13:45   ` David Hildenbrand
2024-04-12  1:34     ` Alistair Popple
2024-04-11  0:57 ` [RFC 10/10] mm: Remove pXX_devmap Alistair Popple
2024-04-11 12:57   ` Jason Gunthorpe
2024-04-11 17:28 ` [RFC 00/10] fs/dax: Fix FS DAX page reference counts Dan Williams
2024-04-11 17:35   ` Jason Gunthorpe
2024-04-11 17:56     ` Dan Williams
2024-04-12  3:54   ` Alistair Popple
2024-04-12  6:55     ` Alistair Popple
2024-04-12 11:53       ` Jason Gunthorpe
2024-04-12 17:32         ` Dan Williams

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=661d9355239bc_4d56129485@dwillia2-mobl3.amr.corp.intel.com.notmuch \
    --to=dan.j.williams@intel.com \
    --cc=apopple@nvidia.com \
    --cc=david@fromorbit.com \
    --cc=david@redhat.com \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=jgg@nvidia.com \
    --cc=jglisse@redhat.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=nvdimm@lists.linux.dev \
    --cc=rcampbell@nvidia.com \
    --cc=ruansy.fnst@fujitsu.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).