cache_read(9)
π cache_read(9) β like, the full manual page, bestie π
okay so this is a page from the Kernel API Manual (section 9, kernel girlies rise) and it's all about cache_read β one of those functions that sounds simple until you read the whole thing. stay with me, it's actually so good β¨
π NAME π
cache_read β processes a read request by, yes, traversing the cache tree π³π
β¨ SYNOPSIS β¨
int cache_read (struct pcache_cache *cache , struct pcache_request
*pcache_req );
that's it. that's the whole signature. two pointers in, an int out, main character energy fr fr π
πΈ ARGUMENTS πΈ
cacheβ the cache structure. it's holding the cache trees and the related configurations, so like, everything the traversal needs to actually do its thing ποΈpcache_reqβ the request structure, and it's carrying all the info about the data you wanna read. basically the ask π
π¦ DESCRIPTION π¦
so here's the vibe: this function tries to fulfill a read request by traversing the cache tree(s) and locating cached data for the requested range. and if parts of the data are justβ¦ not in the cache? π then backing requests get generated to go retrieve the required segments. no data left behind periodt.
the way it works is it initializes a key for the requested data range and preps a context (walk_ctx) to manage the cache tree traversal. and that context is lowkey the whole personality of the function, because it includes pointers to functions that handle specific conditions encountered during the traversal β like read_before and read_overlap_tail. the end stages of the traversal are managed by walk_finally and walk_done, while the delete_key_list and submit_req_list lists keep track of any keys to be deleted or requests to be submitted. bookkeeping slay πβ¨
then, first things first: it calculates the requested range and checks if it fits within the current cache tree (based on the tree's size limits). after that it locks the cache tree π and performs a search to locate any matching keys.
β οΈ okay important bit: if there are outdated keys, those get deleted, and then the search is restarted to make sure the data retrieval is accurate. not optional, not a vibe check you can skip β it's how it stays correct π
and finally, if the requested range spans multiple cache trees, the function moves on to the next tree once the current range has been processed. this just keeps going until the entire requested data length has been handled. multi-tree road trip, we love to see it ππ
π SEE ALSO π
kernel file ./drivers/md/dm-pcache/cache_req.c, plus all of these icons:
cache_data_alloc(9)miss_read_end_req(9)submit_cache_miss_req(9)read_walk_finally(9)pcache_cache_flush(9)
okay that's the whole page, you ate that reading it π«Ά this came out of ./drivers/md/dm-pcache in October 2026 under the Kernel API Manual β go be iconic with your cache reads, ily, bye πππ
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms