dmem_cgroup_try_charge(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– dmem_cgroup_try_charge(9) πŸ’–

okay so bestie, welcome to the Kernel API Manual β€” this one's about the kernel's dmem cgroup stuff, and honestly it's giving "let me try to charge this allocation and see if the region says yes" energy. sit down, grab a matcha πŸ“, we're doing this.


✨ NAME ✨

dmem_cgroup_try_charge β€” try charging a new allocation to a region. that's it, that's the vibe πŸŽ€


🌸 SYNOPSIS 🌸

int dmem_cgroup_try_charge (struct dmem_cgroup_region *region , u64 size
, struct dmem_cgroup_pool_state **ret_pool , struct
dmem_cgroup_pool_state **ret_limit_pool );

like, copy this exactly pls, no cap, the compiler is not forgiving πŸ™ˆ


πŸ¦‹ ARGUMENTS πŸ¦‹

  • region β€” the dmem region you're charging. your main character 🫢
  • size β€” how many bytes you're charging. in bytes, bestie, bytes. πŸ”₯
  • ret_pool β€” on a successful allocation, this gets set to the pool that actually got charged. so you know who took the tab πŸ’…
  • ret_limit_pool β€” on a failed allocation, this is the limiting pool. the one that said "not today" 😭

πŸ’œ DESCRIPTION πŸ’œ

so this function charges the region region for a size of size bytes. that's the whole bit. ⭐

if the function succeeds, ret_pool is set β€” and here's the important part, so listen up: that pool must be passed to dmem_cgroup_uncharge when you're undoing the allocation. don't just vibe off into the sunset and forget it, fr fr 🧚

when this function fails with -EAGAIN and ret_limit_pool is non-null, it gets set to the pool for which the limit is hit. like, it literally tells you which pool is the problem 😀 super useful β€” you can use it for eviction as the argument to dmem_cgroup_evict_valuable. this reference must be freed with dmem_cgroup_pool_state_put. yes, must. not "should". we said what we said. 🎯

okay quick recap because I know you're multitasking: success = ret_pool, and please actually uncharge it later. -EAGAIN + non-null ret_limit_pool = the limiting pool, and please actually put it later. two different refs, two different cleanups. iykyk πŸ’€

🌈 RETURN 🌈

  • 0 on success β€” iconic, we love a zero ✨
  • -EAGAIN on hitting a limit β€” the limit said nah πŸ’…
  • or a negative errno on failure β€” some other little gremlin went wrong πŸ™ˆ

πŸ‘‘ SEE ALSO πŸ‘‘


aaaand that's the page, bestie! this one lives over in ./kernel/cgroup and the version we're looking at is dated October 2026 β€” so like, cosy little kernel-api-manual moment from the future. slay πŸ’–πŸŽ€βœ¨

πŸ“¦ where this page comes from