ENUM PANTHOR_GEM_RECLAIM_STATE(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ NAME ✨

enum panthor_gem_reclaim_state β€” literally the reclaim state of a GEM object, and yes bestie, the whole kernel API manual is gonna walk you through it πŸ’…

This is a page from the Kernel API Manual, so you know it's official official.


🌸 SYNOPSIS 🌸

enum panthor_gem_reclaim_state {
    PANTHOR_GEM_UNUSED ,
    PANTHOR_GEM_MMAPPED ,
    PANTHOR_GEM_GPU_MAPPED_SINGLE_VM ,
    PANTHOR_GEM_GPU_MAPPED_MULTI_VM ,
    PANTHOR_GEM_UNRECLAIMABLE

};

okay so that's the whole enum, and now we're gonna go through every single constant one by one because nobody gets left behind on my watch 🫢


πŸŽ€ Constants πŸŽ€

PANTHOR_GEM_UNUSED

GEM is currently unused πŸŒ™

This can happen when the GEM was previously vmap-ed, mmap-ed, and/or GPU mapped and got unmapped. Because pages are lazily returned to the shmem layer, we want to keep a list of such BOs, because they should be fairly easy to reclaim (no need to wait for GPU to be done, and no need to tear down user mappings either). lowkey the easiest W on the list, ngl ✨

PANTHOR_GEM_MMAPPED

GEM is currently mmap-ed πŸ—ΊοΈ

When a GEM has pages allocated and the mmap_count is > 0, the GEM is placed in the mmapped list. This comes right after unused because we can relatively easily tear down user mappings. it's giving "slightly more work but still cute" πŸ’–

PANTHOR_GEM_GPU_MAPPED_SINGLE_VM

GEM is GPU mapped to only one VM πŸ‘‘

When a GEM is mapped to a single VM, reclaim requests have more chances to succeed, because we only need to synchronize against a single GPU context. This is more annoying than reclaiming mmap-ed pages still, because we have to wait for in-flight jobs to land, and we might not be able to acquire all necessary locks at reclaim time either. not me having to wait for jobs to land 😭

PANTHOR_GEM_GPU_MAPPED_MULTI_VM

GEM is GPU mapped to multiple VMs 🌈

Like PANTHOR_GEM_GPU_MAPPED_SINGLE_VM, but the synchronization across VMs makes such BOs harder to reclaim. more VMs = more chaos, fr fr πŸ’€

PANTHOR_GEM_UNRECLAIMABLE

GEM can't be reclaimed 🚫

Happens when the GEM memory is pinned. It's also the state all GEM objects start in, because no memory is allocated until explicitly requested by a CPU or GPU map, meaning there's nothing to reclaim until such an allocation happens. iconic default behavior honestly β€” nothing to reclaim because there's literally nothing there yet 🫠


πŸ¦‹ Description πŸ¦‹

This is defined in descending reclaimability order and some part of the code depends on that.

⚠️ bestie read that again: descending reclaimability order β€” and some part of the code literally depends on it. do not reorder the enum, i am begging πŸ™

πŸ’œ SEE ALSO πŸ’œ

  • Kernel file ./drivers/gpu/drm/panthor/panthor_gem.h struct panthor_gem_debugfs(9)
  • struct panthor_gem_backing(9)
  • struct panthor_gem_cpu_map(9)
  • struct panthor_gem_dev_map(9)
  • struct panthor_gem_object(9)
  • struct panthor_kernel_bo(9)

aaaand that's the whole page, you ate that πŸ“ this icon of a manpage lives in ./drivers/gpu/drm/panthor, stamped October 2026, titled enum panthor...eclaim_state(9) β€” go forth and reclaim responsibly, mwah πŸ’‹πŸ‘‘

πŸ“¦ where this page comes from