linux-kernel - Re: [PATCH RFC 07/39] mm/rmap: convert folio_add_file_rmap_range() into folio_add_file_rmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3488f910-891d-48bf-a5da-5bc01955b072@redhat.com>
Date:   Wed, 6 Dec 2023 10:17:47 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Yin Fengwei <fengwei.yin@...el.com>, linux-kernel@...r.kernel.org
Cc:     linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
        "Matthew Wilcox (Oracle)" <willy@...radead.org>,
        Hugh Dickins <hughd@...gle.com>,
        Ryan Roberts <ryan.roberts@....com>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Muchun Song <muchun.song@...ux.dev>,
        Peter Xu <peterx@...hat.com>
Subject: Re: [PATCH RFC 07/39] mm/rmap: convert folio_add_file_rmap_range()
 into folio_add_file_rmap_[pte|ptes|pmd]()

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