rds_page_remainder_alloc(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸŽ€ NAME πŸŽ€

rds_page_remainder_alloc β€” bestie, this one's all about building up regions of a message ✨


🌸 SYNOPSIS 🌸

int rds_page_remainder_alloc (struct scatterlist *scat , unsigned long
bytes , gfp_t gfp );

πŸ¦‹ ARGUMENTS πŸ¦‹

  • scat β€” the scatter list for the message, okurrr πŸ’… that's the thing getting filled up.
  • bytes β€” literally the number of bytes needed. that's it, that's the whole vibe.
  • gfp β€” the waiting behaviour of the allocation. yes ma'am, this decides how patient we're being πŸ™ˆ

πŸ’– DESCRIPTION πŸ’–

okay so first thing, gfp is always ored with __GFP_HIGHMEM β€” no exceptions, no cap. so callers must be prepared to kmap the pages, etc. πŸ‘‘

if bytes is at least a full page then this literally just returns a page from alloc_page. simple. iconic. done. ✨

but if bytes is a partial page then it gets interesting β€” this stores the unused region of the page in a per-cpu structure, and future partial-page allocations may be satisfied from that cached region πŸ§šβ€β™€οΈ so cute, so efficient. this lets us waste less memory on small allocations with minimal complexity, which is honestly the whole slay of it.

and the reason it works? the transmit path passes read-only page regions down to devices, and they hold a page reference until they're done with the region. periodt. πŸ’…


πŸ”₯ SEE ALSO πŸ”₯

  • Kernel file ./net/rds/page.c β€” go read it, iykyk 🫢

and that's the whole page bestie!! brought to you by ./net/rds, dated October 2026, for rds_page_remainder_alloc(9) β€” mwah, go touch some pages πŸ’œ

πŸ“¦ where this page comes from