shmem_read_folio_gfp(9)

💖 shmem_read_folio_gfp(9) — the kernel API manual, bestie edition 💖

okay so real talk, this one's from the kernel API manual (section 9, iykyk) and it's literally about reading into the page cache with the page allocation flags you pick. main character energy for a helper function ngl 🎀

---

✨ NAME ✨

shmem_read_folio_gfp — read into page cache, using specified page allocation flags.

🦋 SYNOPSIS 🦋

struct folio * shmem_read_folio_gfp (struct address_space *mapping ,
pgoff_t index , gfp_t gfp );

🌸 ARGUMENTS 🌸

• mapping — the folio's address_space. yes, that one. the space it lives in 💅
• index — the folio index. like, which folio we're talking about 🫶
• gfp — the page allocator flags to use if allocating. your vibe for the allocation, basically ⭐

👑 DESCRIPTION 👑

So here's the tea: this behaves as a tmpfs read_cache_page_gfp(mapping, index, gfp), with any new page allocations done using the specified allocation flags. slay.

But — and this is the plot twist 😭 — read_cache_page_gfp uses the ->read_folio method, which does not suit tmpfs, since it may have pages in swapcache, and needs to find those for itself. so it's out here doing its own thing, looking for its own pages. iconic but chaotic.

although, plot twist part two: drivers/gpu/drm i915 and ttm rely upon this support. so like, don't come for it 🔥

And one more thing, and lowkey this bit matters: i915_gem_object_get_pages_gtt mixes __GFP_NORETRY | __GFP_NOWARN in with the mapping_gfp_mask, to avoid OOMing the machine unnecessarily. not the machine getting OOM'd for no reason 💀 we love a thoughtful flag combo fr fr.

🧚 SEE ALSO 🧚

Kernel file ./mm/shmem.c — the whole friend group:

• shmem_recalc_inode(9)
• shmem_writeout(9)
• shmem_get_folio(9)
• shmem_kernel_file_setup(9)
• shmem_file_setup(9)
• shmem_file_setup_with_mnt(9)
• shmem_zero_setup(9)
• shmem_zero_setup_desc(9)

---

okay that's the whole page bestie, go read some folios 💖✨

mwah, this one's from ./mm, October 2026, and it's shmem_read_folio_gfp(9) — periodt 💅