Re: [PATCH v1 1/3] mm: Allow deferred splitting of arbitrary large anon folios

[David Hildenbrand <david@redhat.com>]

On 17.07.23 17:54, Matthew Wilcox wrote:
> On Mon, Jul 17, 2023 at 05:43:40PM +0200, David Hildenbrand wrote:
>> On 17.07.23 17:41, Ryan Roberts wrote:
>>> On 17/07/2023 16:30, Matthew Wilcox wrote:
>>>> On Mon, Jul 17, 2023 at 03:31:08PM +0100, Ryan Roberts wrote:
>>>>> In preparation for the introduction of large folios for anonymous
>>>>> memory, we would like to be able to split them when they have unmapped
>>>>> subpages, in order to free those unused pages under memory pressure. So
>>>>> remove the artificial requirement that the large folio needed to be at
>>>>> least PMD-sized.
>>>>>
>>>>> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
>>>>> Reviewed-by: Yu Zhao <yuzhao@google.com>
>>>>> Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
>>>>
>>>> Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
>>>
>>> Thanks!
>>>
>>>>
>>>>>    		 */
>>>>> -		if (folio_test_pmd_mappable(folio) && folio_test_anon(folio))
>>>>> +		if (folio_test_large(folio) && folio_test_anon(folio))
>>>>>    			if (!compound || nr < nr_pmdmapped)
>>>>>    				deferred_split_folio(folio);
>>>>
>>>> I wonder if it's worth introducing a folio_test_deferred_split() (better
>>>> naming appreciated ...) to allow us to allocate order-1 folios and not
>>>> do horrible things.  Maybe it's not worth supporting order-1 folios;
>>>> we're always better off going to order-2 immediately.  Just thinking.
>>>
>>> There is more than just _deferred_list in the 3rd page; you also have _flags_2a
>>> and _head_2a. I guess you know much better than me what they store. But I'm
>>> guessing its harder than jsut not splitting an order-1 page?
> 
> Those are page->flags and page->compound_head for the third page in
> the folio.  They don't really need a name; nothing refers to them,
> but it's important that space not be reused ;-)
> 
> This is slightly different from _flags_1; we do have some flags which
> reuse the bits (they're labelled as PF_SECOND).  Right now, it's only
> PF_has_hwpoisoned, but we used to have PF_double_map.  Others may arise.
> 
>>> With the direction of large anon folios (_not_ retrying with every order down to
>>> 0), I'm not sure what the use case would be for order-1 anyway?
>>
>> Just noting that we might need some struct-page space for better
>> mapcount/shared tracking, which might get hard for order-1 pages.
> 
> My assumption had been that we'd be able to reuse the _entire_mapcount
> and _nr_pages_mapped fields and not spill into the third page, but the

We most likely have to keep _entire_mapcount to keep "PMD mapped" 
working (I don't think we can not account that, some user space relies 
on that). Reusing _nr_pages_mapped for _total_mapcount would work until 
we need more bits.

But once we want to sort out some other questions like "is this folio 
mapped shared or mapped exclusive" we might need more space.

What I am playing with right now to tackle that would most probably not 
fit in there (but I'll keep trying ;) ).

> third page is definitely available today if we want it.  I'm fine with
> disallowing order-1 anon/file folios forever.

Yes, let's first sort out the open issues before going down that path 
(might not really be worth it after all).

-- 
Cheers,

David / dhildenb