folio_memcg_list_lru_alloc(9)

📦 version 7.3.1, in nixpkgs unstable

💅 folio_memcg_list_lru_alloc — the Kernel API Manual said "let's get this folio queued up"

okay so real talk, this one lives in the Kernel API Manual section (section 9, kernel girlies know 🎀) and it's all about prepping the little queue-hooks a folio needs before it can actually be parked on a shrinker list later. no cap.

✨ NAME ✨

folio_memcg_list_lru_alloc — allocate list_lru heads for a shrinkable folio 🦋

🌸 SYNOPSIS 🌸

int folio_memcg_list_lru_alloc (struct folio *folio , struct list_lru
*lru , gfp_t gfp );

literally one function, three args, returns an int. that's her 💅

🫶 ARGUMENTS 🫶

  • folio — the newly allocated & charged folio. she's fresh, she's accounted for, she's ready 👑
  • lru — the list_lru this might be queued on. it's giving "potential future home" energy 🏠
  • gfp — the gfp mask. that's the allocation-vibes dial, yw ✨

💖 DESCRIPTION 💖

so what she actually does: she allocates the list_lru heads (per-memcg, per-node) that you're gonna need in order to queue this particular folio down the line. like, not right now, but future-you is gonna be so grateful 🫶

this does memcg_list_lru_alloc, but on the memcg that the folio is associated with. iykyk — different memcg, different bookkeeping.

she also handles the folio_memcg access rules in the fast path (aka: list_lru heads already allocated, we're chilling 😌) and in the allocation slowpath (aka: we gotta go do actual work 😭). both covered, she's so thorough.

✨ returns 0 on success, and a negative error value otherwise. so if your return value is < 0, that's your sign something did not slay. check it 💀

🧚 SEE ALSO 🧚

kernel file ./include/linux/list_lru.h plus the whole list_lru friend group:

🎀 and that's the page bestie! brought to you by ./include/linux, dated October 2026, filed under folio_memcg_list_lru_alloc(9) in the Kernel API Manual. go forth and allocate responsibly 💜🌈⭐
📦 where this page comes from