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