folio_is_file_lru(9)

✨ folio_is_file_lru — the Kernel API Manual tea 🫖

okay bestie, gather round, because today we're learning about folio_is_file_lru from the Kernel API Manual and honestly? it's giving "tiny function, big responsibilities" 💅

---

🌸 NAME 🌸

folio_is_file_lru — so like… should this folio be chilling on the file LRU, or the anon LRU? that's the whole question, no cap 🎀

---

🦋 SYNOPSIS 🦋

int folio_is_file_lru (const struct folio *folio );

literally just one argument and she returns an int. iconic minimalism ✨

---

🍓 ARGUMENTS 🍓

• folio — the folio we're testing. that's it. that's the whole input. she's the main character here 👑

---

💖 DESCRIPTION 💖

so here's the vibe: we would love to get this info without a page flag, but the state needs to survive until the folio is last deleted from the LRU 😭 and that could be, like, way far down — as far down as __page_cache_release. yes bestie, that deep. so we can't just skip the flag, the state has to stick around that long fr fr.

---

🔥 RETURN 🔥

she returns an integer — and not a boolean! (not me stressing this, but the manpage stresses it so I'm stressing it too 💀). it's used to sort a folio onto the right LRU list and to account folios correctly. here's the breakdown:

• 1 — if the folio is a regular filesystem backed page cache folio, or a lazily freed anonymous folio (e.g. via MADV_FREE). slay 🌈
• 0 — if the folio is a normal anonymous folio, a tmpfs folio, or otherwise ram or swap backed folio. also valid, just different vibes 🫶

lowkey important: integer, not boolean. 1 and 0 are doing real semantic work here, not just yes/no energy. respect it 🙈

---

🧚 SEE ALSO 🧚

• Kernel file ./include/linux/mm_inline.h
• __folio_clear_lru_flags(9)
• folio_lru_list(9)
• num_pages_contiguous(9)

go read those too, iykyk 💜

---

okay that's the whole page bestie, you ate that 🍓✨ and for the cute sign-off: this little beauty comes from ./include/linux and is dated October 2026 — mark your calendars, the future is now 💅👑🌸