Re: [RFC PATCH 0/5] Separate compound page from folio

["David Hildenbrand (Arm)" <david@kernel.org>]

Sorry for the late reply on this.

>> As discussed, the issue is still that interpret non-folio page
>> allocations as folios, which can also be compound pages.
>>
>> Now, there are PFN walkers that do that, but also page table handling code.
>>
>> Most prominently, when mapping such pages through vm_insert_pages(), we
>> will call into folio_add_file_rmap_pte() and essentially touch mapcount
>> related stuff.
>>
>> Once in the page tables, users can GUP them and modify the pincount.
>> Other page table walkers can just similarly find them and look them up.
>>
>> To stop messing with mapcounts is easy once we can reliably identify
>> such pages when mapping/unmapping them.
> 
> My current way of doing that is to mark every page “NotRmappable” page_type
> in post_alloc_hook() and clear this page_type at page_rmappable_folio().
> Any user wants to set their own page_type can overwrite “NotRmappable”.
> And folio_test_rmappable() is just !folio_has_type(). One exception
> is hugetlb, since it has page_type and is rmappable. Fortunately or
> unfortunately, rmap.c has special handling code for hugetlb, so there
> should be no problem.
> 
> I did some test using io_uring (via nvim), which uses compound page instead of
> folio and does vm_insert*(). At least no crash was present.
> 

We discussed that in the meantime elsewhere. :)

>>
>> GUP and other page table walkers are more problematic and need more
>> thought (and work :( ).
>>
>> Essentially, vm_normal_folio() would have to fail on these pages. But
>> what to do about vm_normal_page() users? The page_folio() would have to
>> fail. But then we must keep some page table walkers working.
>>
>> And we have to figure out what to do with GUP.
> 
> Since _pincount will not be present after my change, GUP cannot be applied
> on these pages.
> 
> OK, my memory comes back. I think my original proposal of separating
> compound page from folio might not be right, since that defeats the
> purpose of folio, which is a group of pages managed as a whole.
> 
> Basically a compound page should still be regarded as a folio, but rmappable
> related fields (e.g., _large_mapcount, _nr_pages_mapped, _mm_ids)
> should not be initialized and user is free to use them differently.
> In this way, _pincount can be a common folio field to initialize and use.

At least long term a non-folio page should not be regarded a folio.

There are quite some changes required to teach page table walkers (incl.
GUP) about that.

In GUP code, we would not mess with the _pincount for non-folio things.
It will be a bit tricky.

Handling the rmap (skip it) as a first step might be easier.

> 
>>
>> So compound pages are just the tip of the iceberg :)
>>
>>
>> We could maybe forbid mapping them through vm_insert_pages() in the
>> first place, requiring all callers to do order-0 page allocations. Hm.
>>
>> Then at least they would not end up in user page tables.
> 
> Will it kill performance? If only order-0 pages are allowed.

I don't think this is really performance-relevant for the
vm_insert_pages() interface. We never get PMD-THPs either way.

But yea, if we could keep that compound pages working that would also
make our life easier.

> 
>>
>> But there is other code where compound pages are interpreted as folios
>> and the other way around that must be sorted out.
> 
> I think we might want to have some sub-class of folios, like rmappable folios,
> not rmappable folios, and others, otherwise, we are going back
> to mixing page and folio.

I think it's pretty clear that a folio will be mappable.

If you want something that is not mappable, then you shouldn't be
allcoating a folio that carries metadata for storing all that information.

-- 
Cheers,

David