On 23.10.24 13:38, Kirill A. Shutemov wrote:
On Thu, Aug 29, 2024 at 06:56:07PM +0200, David Hildenbrand wrote:
Let's free up some more of the "unconditionally available on 64BIT"
space in order-1 folios by letting _folio_nr_pages overlay memcg_data in
the first tail page (second folio page). Consequently, we have the
optimization now whenever we have CONFIG_MEMCG, independent of 64BIT.
We have to make sure that page->memcg on tail pages does not return
"surprises". page_memcg_check() already properly refuses PageTail().
Let's do that earlier in print_page_owner_memcg() to avoid printing
wrong "Slab cache page" information. No other code should touch that
field on tail pages of compound pages.
Reset the "_nr_pages" to 0 when splitting folios, or when freeing them
back to the buddy (to avoid false page->memcg_data "bad page" reports).
Note that in __split_huge_page(), folio_nr_pages() would stop working
already as soon as we start messing with the subpages.
Most kernel configs should have at least CONFIG_MEMCG enabled, even if
disabled at runtime. 64byte "struct memmap" is what we usually have
on 64BIT.
While at it, rename "_folio_nr_pages" to "_nr_pages".
Signed-off-by: David Hildenbrand <david@xxxxxxxxxx>
Reviewed-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx>
BTW, have anybody evaluated how much (if anything) do we gain we a
separate _nr_pages field in struct folio comparing to calculating it
based on the order in _flags_1? Mask+shift should be pretty cheap.
I recall that Willy did, and it's mostly getting rid of a single
instruction in loads of places.
$ git grep folio_nr_pages | wc -l
254
[my first intuition was also to just remove it, but this way seems easy
to just maintain it for now]
--
Cheers,
David / dhildenb
