Andrew Morton wrote: > On Tue, 7 Jan 2025 14:42:16 +1100 Alistair Popple <apopple@xxxxxxxxxx> wrote: > > > 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. > > > > https://lkml.kernel.org/r/wysuus23bqmjtwkfu3zutqtmkse3ki3erf45x32yezlrl24qto@xlqt7qducyld > made me expect merge/build/runtime issues, however this series merges > and builds OK on mm-unstable. Did something change? What's the story > here? > > Oh well, it built so I'll ship it! So my plan is to review this latest set on top of -next as is and then rebase (or ask Alistair to rebase) on a mainline tag so I can identify the merge conflicts with -mm and communicate those to Linus. I will double check that you have pulled these back out of mm-unstable before doing that to avoid a double-commit conflicts in -next, but for now exposure in mm-unstable is good to flush out issues.
