On 14.12.24 02:39, Dan Williams wrote:
[ add akpm and sfr for next steps ] Alistair Popple wrote:Main updates since v2: - Rename the DAX specific dax_insert_XXX functions to vmf_insert_XXX and have them pass the vmf struct. - Seperate out the device DAX changes. - Restore the page share mapping counting and associated warnings. - Rework truncate to require file-systems to have previously called dax_break_layout() to remove the address space mapping for a page. This found several bugs which are fixed by the first half of the series. The motivation for this was initially to allow the FS DAX page-cache mappings to hold a reference on the page. However that turned out to be a dead-end (see the comments on patch 21), but it found several bugs and I think overall it is an improvement so I have left it here. Device and FS DAX pages have always maintained their own page reference counts without following the normal rules for page reference counting. In particular pages are considered free when the refcount hits one rather than zero and refcounts are not added when mapping the page. Tracking this requires special PTE bits (PTE_DEVMAP) and a secondary mechanism for allowing GUP to hold references on the page (see get_dev_pagemap). However there doesn't seem to be any reason why FS DAX pages need their own reference counting scheme. By treating the refcounts on these pages the same way as normal pages we can remove a lot of special checks. In particular pXd_trans_huge() becomes the same as pXd_leaf(), although I haven't made that change here. It also frees up a valuable SW define PTE bit on architectures that have devmap PTE bits defined. It also almost certainly allows further clean-up of the devmap managed functions, but I have left that as a future improvment. It also enables support for compound ZONE_DEVICE pages which is one of my primary motivators for doing this work.So this is feeling ready for -next exposure, and ideally merged for v6.14. I see the comments from John and Bjorn and that you were going to respin for that, but if it's just those details things they can probably be handled incrementally. Alistair, are you ready for this to hit -next? As for which tree... Andrew, we could take this through -mm, but my first instinct would be to try to take it through nvdimm.git mainly to offload any conflict wrangling work and small fixups which are likely to be an ongoing trickle. However, I am not going to put up much of a fight if others prefer this go through -mm. Thoughts?
I'm in the process of preparing v2 of [1] that will result in conflicts with this series in the rmap code (in particular [PATCH v3 14/25] huge_memory: Allow mappings of PUD sized pages).
I'll be away for 2 weeks over Christmas, but I assume I'll manage to post v2 shortly.
Which reminds me that I still have to take a closer look at some things in this series :) Especially also #14 regarding accounting.
I wonder if we could split out the rmap changes in #14, and have that patch simply in two trees? No idea.
[1] https://lore.kernel.org/all/20240829165627.2256514-1-david@xxxxxxxxxx/T/#u
-- Cheers, David / dhildenb
