MEMDESC Allocation

### Overview In this talk, Matthew Wilcox presents development notes and architectural proposals for the ongoing evolution of Linux kernel memory descriptors, following the transition toward memory folios. The primary objective is to significantly reduce the overhead of `struct page` from its current 64-byte size down to 16 bytes or even a single 64-bit value (`u64`) by decoupling tracking metadata into dynamically allocated or specialized memory descriptors (`memdesc`).

### Key Topics - **Memdesc Typing & Bit Stuffing**: Using the lower 4 bits of a descriptor reference to differentiate underlying types (such as folios, slab allocations, network memory, or anonymous folios), leaving open possibilities for type hierarchies and subtypes. - **The Miscellaneous (`misk`) Memory Type**: For unspecialized kernel allocations (like device driver `alloc_page`, BRD RAM disks, or `vmalloc` buffers), storing allocation metadata directly inline within unused bits instead of creating external pointer references. - **Buddy Allocator Integration**: Strategies for representing buddy allocator tracking (`struct buddy`) within constrained descriptor sizes without incurring recursive memory allocation during page free paths. - **Staging and Implementation Plan**: Incremental steps to deprecate legacy fields (such as `page->mapping` and `page->index`), split specialized users out of `struct page`, and benchmark potential cache and lookup performance impacts.

### Technical Details - **Descriptor Pointer Encoding**: The proposed pointer uses low bits to identify memory descriptor types. For miscellaneous types (type 0), subtype identifiers occupy bits 4–10, allocation order uses bits 12–17, and high bits store section/node/zone information (resembling `folio->flags`). This distinguishes mappings such as user-mappable versus non-mappable `vmalloc` (e.g., preventing kernel stack mapping to user space). - **Translation Semantics**: `mmap` persists as an array of `struct page`. PFN-to-page translation remains identical, while PFN-to-folio translates via dereferencing the descriptor pointer. If the type does not match a folio, helper functions like `pfn_to_folio()` would return `NULL`. - **Buddy List Representation Options**: 1. *Two `u64` entries (16 bytes)*: Maintains separate descriptor and `struct buddy` pointers with next/previous links. 2. *PFN indexing*: Stores PFN offsets instead of 64-bit pointers. 3. *Compressed single `u64`*: Restricts addressable physical memory limits (e.g., capping support to ~2 TB). 4. *Zone-relative PFNs*: References page frame numbers relative to the base of each memory zone, accommodating large multi-terabyte systems by leveraging natural NUMA and zone boundaries while potentially mitigating LRU lock contention. - **Staging Strategy**: Renaming core members (e.g., `page->mapping` to `__folio_mapping`) to eliminate direct legacy consumers before shrinking `struct page` and testing separately allocated descriptor performance.

### Takeaways Transitioning to specialized memory descriptors offers drastic memory savings for large-scale systems, reducing descriptor footprint by up to 75–87.5%. However, implementation requires careful handling of buddy allocator operations, memory section sizing tradeoffs, and comprehensive benchmarking to verify that extra dereferences do not introduce noticeable performance regressions.