Received-SPF: pass (google.com: domain of linux-ext4+bounces-2095-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Mon, 15 Apr 2024 17:36:59 -0700
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
Message-ID: <661dc82bd6c77_36222e29493@dwillia2-xfh.jf.intel.com.notmuch>
References: <cover.fe275e9819458a4bbb9451b888cafb88af8867d4.1712796818.git-series.apopple@nvidia.com>
 <322065d373bb6571b700dba4450f1759b304644a.1712796818.git-series.apopple@nvidia.com>
 <20240412152208.m25mjo3xjfyawcaj@quack3>
 <66197008db9fc_36222e294b8@dwillia2-xfh.jf.intel.com.notmuch>
 <878r1f2jko.fsf@nvdebian.thelocal>
 <661d9355239bc_4d56129485@dwillia2-mobl3.amr.corp.intel.com.notmuch>
 <87h6g2b1qs.fsf@nvdebian.thelocal>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87h6g2b1qs.fsf@nvdebian.thelocal>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?uMx+TZiaTGTvVo3/EphtUTD0Z3/+y6RIhinl5bz8oPKq263yE4Mo6Js+Wxal?=
 =?us-ascii?Q?wULf5O8j6IFr8s/MBXsa3SloTK8kBFRw0qAkehEK/C8DejYZeMW4dcnWgbXy?=
 =?us-ascii?Q?xZHXfn4q8HpEglGNN3f1SS7521fauY78z+MhG1KHPFEzw35Zchwh43subrjs?=
 =?us-ascii?Q?Xs9exOyYJztyWmLi4QR81Wa6gtnoWSSbmpOnwVBcYT1JEgYxZIeUlJ7L3g8f?=
 =?us-ascii?Q?bZeNkG9X5hadtuNh/1u3oOLydxIjdFfqiZlFtK2ymhV65ILnQrqV8DITvWSF?=
 =?us-ascii?Q?waT2MFQi5tTz3vtj9rG2IEWRViFttD93xnQl/PVbME9DIAClAq4UkTChnH9i?=
 =?us-ascii?Q?sCu4oUxw6V4ZGc7qsI7hnkh/SdD8gsChGBS3cuUdq4oLuCOnnV/jcjTlnOFj?=
 =?us-ascii?Q?iw0/ceHjF5TfXmr2cTpsRbbH2Tk6sb/IkJVIFIxjoOr5eutkyzhrvi9tChAz?=
 =?us-ascii?Q?6bQ1PEbmOEUxhchDwenyotGEcyl9MZWhmZJTHPHeP0ikygictJkmJyTUZSod?=
 =?us-ascii?Q?AaPQWpUFElD1GAE3Eh3HTpCmftAb7sGd+Amb0LkkESXlrLt7yc9j1FvbnOM1?=
 =?us-ascii?Q?XWpMpO5u5TDjxmnLMIigajkeEi1x7yo4ZJp+rjW+MMdtMbJ8LqbrKyDKEzTF?=
 =?us-ascii?Q?n7sVmaGWTCcuZysMjdWlbcih2S3tCEEenVAEdB2mo8ReHlTuwZ2wfF0rPped?=
 =?us-ascii?Q?JXTqu2VzSC5+yUHZWxt2w1KgTXqbzb2wFd+0qBSizGYGQZIf6I6QGEjzH8N5?=
 =?us-ascii?Q?T9x7tko8uZZh4IPEmsiK/PHK6Hh6wDFxVqBFpGaCBWj2JbIw30YuuZ8kErYQ?=
 =?us-ascii?Q?0yQ+/skEnwM9gZgFr9f4qDMVAsllYbCbiPwI86TWEhUV0KxCJvLQO3AsIZ0/?=
 =?us-ascii?Q?dHUYbQBHinAljI9L7/jzKgL6yAhvCIgl0jZbHRLthP9UOXxedNu9Q7+zE2Og?=
 =?us-ascii?Q?GFiH1vUHQH8IAQEPnxW1ni7jeITuiqXEzhf85xWyxurz2zkET6Om2GVPj3SP?=
 =?us-ascii?Q?SHAUbOcpEnI6/hLlwDWh+pIpUZGrlZpYnSE+YZ62AVYokq7wDRu2WWh7+2q0?=
 =?us-ascii?Q?Z6IFJrZPoAhF47/vZ7H7VKE0gxY/QZa60dlyZKR6eOCXqe3mSJkRlk7M4s5v?=
 =?us-ascii?Q?oJ8vmpSdhb6laTrO9fKE5m8Y63/ldFReCNgOpHmbINcAmSuxOh8IzLzQDTgZ?=
 =?us-ascii?Q?PsXREu6JWp5aTWyerSreFkkgI4tpqfG2kV1zNA8JcEQiPCmu/+4NUREDoTSB?=
 =?us-ascii?Q?5gAfWs0uDuUgppJxJ8FmdIcfb1XdZ+DRJ3Gmsv0oqDDHvSOFQzjcfbMnIKq4?=
 =?us-ascii?Q?JferWKLbmvtXbZgj+cTRaDhvRq1umbCQmp/P/lLPXvyuYoxuVRX9SDJ2Tnkm?=
 =?us-ascii?Q?M5RvUTSRTdR/uCoVYeyRokYAC6+esBock5xiz2nTFx/ZAAmcmhPXECkL4W0m?=
 =?us-ascii?Q?79yvY2ZGeO/4BpYYapoE9t2d3Y+fTSbMn1H4quqQI5VIw2FJMrwWEzFMuB2Z?=
 =?us-ascii?Q?v5RQ29egPED7u3UVtjaBez45T3uUPnUkg9D7ma78F8vOrA1Y52Hjh+CBrkO/?=
 =?us-ascii?Q?VjX2oTGSx7MFjMyk7OqnWBabTM6CRN4SM2MtWHoSn3QFFjlzESOQvcrUbZOS?=
 =?us-ascii?Q?YQ=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 9018afe9-2e8e-453c-8235-08dc5dad55aa
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2024 00:37:02.9622
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: JA+KEKPYjCcxJ4NLY3h2Zb7zCUkAvQbN2j2LJEruuXJzIKmfOpHXaC840giPNGLwtYvz2vjj96VlfiN/locHq0rtZjCnLa3Vl064NOr/T58=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR11MB8006
X-OriginatorOrg: intel.com

Alistair Popple wrote:
> 
> Dan Williams <dan.j.williams@intel.com> writes:
> 
> > 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...
> 
> From what I see we currently (in v6.6) have this in
> __split_huge_pmd_locked():
> 
>         if (!vma_is_anonymous(vma)) {
>                 old_pmd = pmdp_huge_clear_flush_notify(vma, haddr, pmd);
>                 /*
>                  * We are going to unmap this huge page. So
>                  * just go ahead and zap it
>                  */
>                 if (arch_needs_pgtable_deposit())
>                         zap_deposited_table(mm, pmd);
>                 if (vma_is_special_huge(vma))
>                         return;
> 
> Where vma_is_special_huge(vma) returns true for vma_is_dax(). So AFAICT
> we're still skipping the split right? In all versions we just zap the
> PMD and continue. What am I missing?

Ah, good point I missed that. One more dragon vanquished.