ttm_lru_walk_for_evict(9)

📦 version 7.3.1, in nixpkgs unstable

👑 ttm_lru_walk_for_evict(9) — like, the LRU walker that actually does stuff 💅

okay so this is from the Kernel API Manual, and bestie, it's a whole vibe: we're walking a LRU list and doing things to the valid items we find. no cap, it's giving main character energy 🦋

✨ NAME ✨

ttm_lru_walk_for_evict — perform a LRU list walk, with actions taken on valid items. literally what it says on the tin 🎀

🌸 SYNOPSIS 🌸

s64 ttm_lru_walk_for_evict (struct ttm_lru_walk *walk , struct
ttm_device *bdev , struct ttm_resource_manager *man , s64 target );

💖 ARGUMENTS 💖

  • walk — describes the walk and the actions taken, iykyk 👑
  • bdev — the TTM device, periodt.
  • man — the struct ttm_resource manager whose LRU lists we're walking, like, that's the whole assignment 💅
  • target — the end condition for the walk. yes, it's a condition, not necessarily a page count, we'll get there 🫶

🦋 DESCRIPTION 🦋

so. the LRU lists of man get walked, and for each struct ttm_resource we bump into, the corresponding ttm_buffer_object gets locked and we take a reference on it, and then the LRU lock is dropped. and yes, the LRU lock may be dropped before locking — and in that case, it's verified that the item actually remains on the LRU list after the lock, and that the buffer object didn't switch resource in between. no sneaky resource-switching on our watch 💀

with a locked object, the actions indicated by walk->process_bo are performed, and after that the bo is unlocked, the refcount dropped, and the next struct ttm_resource is processed. here, the walker relies on TTM's restartable LRU list implementation. iconic behaviour, honestly ✨

typically walk->process_bo would return the number of pages evicted, swapped or shrunken, so that when the total exceeds target, or when the LRU list has been walked in full, iteration is terminated. it's also terminated on error. 🛑

note that the definition of target is done by the caller — it could have a different meaning than the number of pages. so like, don't assume, bestie 🙈

and one more thing that lowkey matters a lot: note that the way dma_resv individualization is done, locking needs to be done either with the LRU lock held (trylocking only) or with a reference on the object. that's the rule, fr fr 🔥

⭐ RETURN ⭐

the progress made towards target, or a negative error code on error. simple as that 💜

🌈 SEE ALSO 🌈

kernel file ./drivers/gpu/drm/ttm/ttm_bo_util.c, plus all of these besties:

and that's the page, bestie!! 🎀 brought to you by ./drivers/gpu/drm/ttm, dated October 2026 — like, mark your calendars, this one's a keeper 💖✨

📦 where this page comes from