On 06.12.23 02:30, Yin Fengwei wrote:
On 12/4/23 22:21, David Hildenbrand wrote:
Let's get rid of the compound parameter and instead define implicitly
which mappings we're adding. That is more future proof, easier to read
and harder to mess up.
Use an enum to express the granularity internally. Make the compiler
always special-case on the granularity by using __always_inline.
Add plenty of sanity checks with CONFIG_DEBUG_VM. Replace the
folio_test_pmd_mappable() check by a config check in the caller and
sanity checks. Convert the single user of folio_add_file_rmap_range().
This function design can later easily be extended to PUDs and to batch
PMDs. Note that for now we don't support anything bigger than
PMD-sized folios (as we cleanly separated hugetlb handling). Sanity checks
will catch if that ever changes.
I do have a question for the folio which has larger size than PMD in the
future:
Will the folio size be only just like PMD size/PUD size? Or it's possible between
PUD size and PMD size?
I strongly assume that we'll see in the future folios larger than a
single PMD (for example, 4 MiB on x86-64).
This will require quite some care in other areas (and this series, as it
converts some PMD handling function to folios, further prepares for that).
If it's possible between PUD size and PMD size, will the mapping be mixed PMD mapping
and PTE mapping or just PTE mapping. I suppose it could be mixed because of efficiency
of page walker.
Depending on with which alignment such larger folios are mapped into the
page tables and some other factors, we might indeed end up having parts
of the folio mapped by PMDs and parts by PTEs. Well, and once we involve
PUDs we might have a mixture of all of these :)
The current API here will be able to deal with that (excluding the _pud
variant). To improve performance, we might want PMD batching and have
_pmds functions.
We'll have to tweak the rmap internals to do the rmap accounting
properly then (and the sanity checks will catch any of that and
highlight the need for rmap-internal extensions); maybe once we come to
that, we no longer have these subpage mapcounts, but we'll have to see
if/when/how that happens.
It may just be too early to consider this now.
I had that in mind while working on this. I assume it will take some
more time to handle everything else that needs to be prepared for that,
but the rmap interface should be able to handle that, only the internals
will have to be extended.
Thanks!
--
Cheers,
David / dhildenb
