gpu_buddy_block_trim(9)

📦 version 7.3.1, in nixpkgs unstable

✨ gpu_buddy_block_trim ✨

okay bestie, welcome to the Kernel API Manual entry for gpu_buddy_block_trim(9) — yes that's the whole name, yes it's a mouthful, no we're not changing it 💅

🌸 NAME 🌸

gpu_buddy_block_trim — frees the pages you didn't end up needing. literally just giving unused pages their freedom 🦋

🎀 SYNOPSIS 🎀

int gpu_buddy_block_trim (struct gpu_buddy *mm , u64 *start , u64
new_size , struct list_head *blocks );

like, that's the whole vibe check right there 👑

💖 ARGUMENTS 💖

  • mm — the GPU buddy manager. your main character struct 🫶
  • start — the start address where the trimming begins. where the glow-up starts, basically ✨
  • new_size — the original size that was requested. the size you actually wanted, before the power-of-two rounding jumped in 😭
  • blocks — input and output list of allocated blocks. this one's doing double duty, iykyk. it MUST contain a single block as input to be trimmed. on success it'll contain the newly allocated blocks making up the new_size. and the blocks always appear in ascending order, no chaos allowed 🔥

🦋 DESCRIPTION 🦋

so for contiguous allocation we round the size up to the nearest power of two value. but the drivers only consume the actual size, which means the remaining portions are just sitting there unused 🙈 — and you can optionally free them with this function. it's giving "decluttering my room" energy ngl 🌸

⭐ RETURN ⭐

0 on success, error code on failure. that's it, that's the whole range 💀

🌈 SEE ALSO 🌈

Kernel file ./drivers/gpu/buddy.c plus all these besties:

💜 quick reminder bestie: the blocks list is in and out. one single block goes in, the new set of blocks comes out, ascending order, no exceptions. don't come for me, that's just what the manpage says 🫶

and that's a wrap, queen 👑 — this lil page lives in ./drivers/gpu and it's dated October 2026, so go forth and trim those unused pages, periodt 🎀💖

📦 where this page comes from