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@xxxxxxx>
Reviewed-by: Yu Zhao <yuzhao@xxxxxxxxxx>
Reviewed-by: Yin Fengwei <fengwei.yin@xxxxxxxxx>
Reviewed-by: Matthew Wilcox (Oracle) <willy@xxxxxxxxxxxxx>
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
