Re: [LSF/MM/BPF TOPIC] Reclaiming & documenting page flags

[Navid <navid.emamdoost@gmail.com>]

On Mon, 2024-01-29 at 04:32 +0000, Matthew Wilcox wrote:
> Our documentation of the current page flags is ... not great.  I think
> I can improve it for the page cache side of things; I understand the
> meanings of locked, writeback, uptodate, dirty, head, waiters, slab,
> mlocked, mappedtodisk, error, hwpoison, readahead, anon_exclusive,
> has_hwpoisoned, hugetlb and large_remappable.
> 
> Where I'm a lot more shaky is the meaning of the more "real MM" flags,
> like active, referenced, lru, workingset, reserved, reclaim, swapbacked,
> unevictable, young, idle, swapcache, isolated, and reported.
> 
> Perhaps we could have an MM session where we try to explain slowly and
> carefully to each other what all these flags actually mean, talk about
> what combinations of them make sense, how we might eliminate some of
> them to make more space in the flags word, and what all this looks like
> in a memdesc world.
> 
> And maybe we can get some documentation written about it!  Not trying
> to nerd snipe Jon into attending this session, but if he did ...
> 
> [thanks to Amir for reminding me that I meant to propose this topic]
> 

On the "Reclaiming" part of this thread, we might consider this:

Optimizing Page Flags: Reclaiming Bits in page->flags via folio->lru

Limited bit space in the Linux kernel's page->flags field, especially on 32-bit
architectures, is a source of challenge [1]. This proposal aims to free up bits
by relocating flags like PG_active and PG_unevictable to the lower bits of
folio->lru as they are always unset. It helps with encoding zone, numa node,
and sparsemem section [2].

Proposed Process:

Candidate Evaluation: Assess flags for relocation suitability based on usage,
dependencies, and functional impact.
Impact Assessment: Evaluate the impact on kernel code to ensure correct behavior
and compatibility.
Relocation Implementation: Modify code to read/write flags from folio->lru and
adjust related macros/functions.
Thoroughly test changes.

[1] https://lwn.net/Articles/335768/
[2] https://blogs.oracle.com/linux/post/struct-page-the-linux-physical-page-frame-data-structure