David Hildenbrand <david@xxxxxxxxxx> writes:
On 02.07.24 12:19, Alistair Popple wrote:
David Hildenbrand <david@xxxxxxxxxx> writes:
On 27.06.24 02:54, Alistair Popple wrote:The aim of the series is make FS DAX and other ZONE_DEVICE pages
Currently DAX folio/page reference counts are managed differently to
normal pages. To allow these to be managed the same as normal pages
introduce dax_insert_pfn_pud. This will map the entire PUD-sized folio
and take references as it would for a normally mapped page.
This is distinct from the current mechanism, vmf_insert_pfn_pud,
which
simply inserts a special devmap PUD entry into the page table without
holding a reference to the page for the mapping.
Do we really have to involve mapcounts/rmap for daxfs pages at this
point? Or is this only "to make it look more like other pages" ?
look
like other pages, at least with regards to the way they are refcounted.
At the moment they are not refcounted - instead their refcounts are
basically statically initialised to one and there are all these special
cases and functions requiring magic PTE bits (pXX_devmap) to do the
special DAX reference counting. This then adds some cruft to manage
pgmap references and to catch the 2->1 page refcount transition. All
this just goes away if we manage the page references the same as other
pages (and indeed we already manage DEVICE_PRIVATE and COHERENT pages
the same as normal pages).
So I think to make this work we at least need the mapcounts.
We only really need the mapcounts if we intend to do something like
folio_mapcount() == folio_ref_count() to detect unexpected folio
references, and if we have to have things like folio_mapped()
working. For now that was not required, that's why I am asking.
Oh I see, thanks for pointing that out. In that case I agree, we don't
need the mapcounts. As you say we don't currently need to detect
unexpect references for FS DAX and this series doesn't seek to introduce
any new behviour/features.
Background also being that in a distant future folios will be
decoupled more from other compound pages, and only folios (or "struct
anon_folio" / "struct file_folio") would even have mapcounts.
For example, most stuff we map (and refcount!) via vm_insert_page()
really must stop involving mapcounts. These won't be "ordinary"
mapcount-tracked folios in the future, they are simply some refcounted
pages some ordinary driver allocated.
Ok, so for FS DAX we should take a reference on the folio for the
mapping but not a mapcount?