Received-SPF: pass (google.com: domain of linux-ext4+bounces-2094-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
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>
User-agent: mu4e 1.10.8; emacs 29.1
From: Alistair Popple <apopple@nvidia.com>
To: 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: Tue, 16 Apr 2024 10:07:16 +1000
In-reply-to: <661d9355239bc_4d56129485@dwillia2-mobl3.amr.corp.intel.com.notmuch>
Message-ID: <87h6g2b1qs.fsf@nvdebian.thelocal>
Content-Type: text/plain
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?Uvr2ZsR2hYkU4CywJklD26nFxTn2y1dsoe9Ekp8Oq54t0oDjf3Mx3G9vvmb5?=
 =?us-ascii?Q?ZpZk1kIOt1A1EYFU2QmCgsHOwpM5mx3/AsBGBXlo0RWIT9PFSB1KjSHQIQfg?=
 =?us-ascii?Q?xd62KlDXA+75PJQbmFE9AWff237BH9r+3sPtcsURh0Ra0q193a7bOZKyPwDC?=
 =?us-ascii?Q?WEPzWvOBecW9YF4nnnI2a9DYTFXQdiofrrB/AtGz8o147A+cRaiWDKUEXUn0?=
 =?us-ascii?Q?xt22D6f9p4pOmowWxxhmJk1WmBVpGt9AadrRkYCxXxCchtXdEAZnOcnFZh+v?=
 =?us-ascii?Q?3uuAd3Juay6op05gZtKwhKjpGIcI37Qjii292e0hdBHsk9R0XHeUsrf58ws6?=
 =?us-ascii?Q?N8kHYGnIrgFN/O+FupXmpTMhMpYYweWthK36Fsr/3JFxYNS0A0ksGkUG7R15?=
 =?us-ascii?Q?GbQNvK8Tg956Kk84alooFhOmUY4CWRzKgftujB+KcHGDAwPnXhA+LrihNst8?=
 =?us-ascii?Q?ldOZEUQF87v53XkNB7IG5e1SAigPwkSQlWOZl7xo2UU9eYsudH59JmoFeBA9?=
 =?us-ascii?Q?fXKDETdJhA9myM+6xH6NTkEn7Q+ez1LqBLzeI8uP+Lvo3yo/dyxOBQRw6hY5?=
 =?us-ascii?Q?4+CQ1JKYsLbNJMVwMwBMa0rMQVUHttCTBXaevlHU55iZJoCmrFY070Q5JG/I?=
 =?us-ascii?Q?z6NlydInVtYX3hK1Q60H/haAf/tQXsBnrIv0UzD4phDZJSO0hliRhwoyl0Zp?=
 =?us-ascii?Q?s5v9LiU/4ePUoGK1g7Lpj8bJ3lC1yXY1Wgh65pc5x1c7WuWixddcEa1kXgjm?=
 =?us-ascii?Q?EhwYr3BgT8mOU3X/zWwvt/+nuNHcnOejs4RvfexQCxvSIO9ZO55QJKkjEqVZ?=
 =?us-ascii?Q?HweoKM+TVjLzF1Bu8A5lkZDBXckh7DYpJyqBPSUaFa7eH4z4LzOC0cGe0I7M?=
 =?us-ascii?Q?EK8NZBfY/PBhPa2vwjtAQgZQgjvveCCHOnJxSgywshId8NWNLAEhd1aGWnTm?=
 =?us-ascii?Q?4PeWkLCX9txLx03FfofF5GH82qs6LSswRbW/dF0P8VxO9cam/g07TCDbQ4sH?=
 =?us-ascii?Q?mG1GVsG+Yh/TXTzz7A5b8FkBSzPWRsKB7J985xODosn9/c9PaTj/SGkLTS9L?=
 =?us-ascii?Q?RF/S5lC5lBpfbQHk7iICKU5dGaBGBtbkC5KNFUQxYQ3NhRBRIh1y5T3AP3+G?=
 =?us-ascii?Q?IbpO7ojUwtUHTay8rZV1K68JiEPqO5XpcbhJ3R5Hdh6Yj5nhOxNoTTftuPi7?=
 =?us-ascii?Q?6gJcfTXU9VN5XiqBxGomvmxOlrtXC7T0dLRyfUFxPOnZuKOYwG6QDTtCPhJw?=
 =?us-ascii?Q?TdbHBoG9uCCT6E/7yT3MKzUX5cxX2UNySgABoo4j3hkd1wgv96rVBTYcf+26?=
 =?us-ascii?Q?SRsjYpcKhOC5LrcdrNSRyJRNlJRQT3URUiRHDvfykBO+v/LgVIWmnHbygwPw?=
 =?us-ascii?Q?Z4CM6XiMnL93wZFjVWHWpdX/eR4f9BqSKiSjlI36QZ/lI8ymAaYy8imgKGYn?=
 =?us-ascii?Q?/skz7CbwsSlAK6qvtwQqEdieG0EfPCrXM4vIcro7qmqqrQXyrdjuJINNMFNT?=
 =?us-ascii?Q?fXQwMsLypjqV8qIE4SpNOTImEAFTj7tSbklTLdWDi7O7mV8VBaqmHh6XEHRa?=
 =?us-ascii?Q?pqwdNLcwMGb1RbLJpdZtNFo7+b5GabLfFGZkTqSx?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ac7a7bc6-a3a4-4461-f7e5-08dc5daa82ce
X-MS-Exchange-CrossTenant-AuthSource: DS0PR12MB7726.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2024 00:16:50.3507
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: XfilfvRJ2IuIfy+2RqtrB2aI7S0Thc44ADuKJ1qTFk8LuJ5hNwUEN934ZMHialbTmiom5jpsEaOz6K9x6a+nKQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8727


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?

> 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.