Re: [PATCH RFC 07/39] mm/rmap: convert folio_add_file_rmap_range() into folio_add_file_rmap_[pte|ptes|pmd]()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux