find_acpi_c...evel_from_id(9)

📦 version 7.3.1, in nixpkgs unstable

🎀 find_acpi_cache_level_from_id — from the Kernel API Manual (section 9), bestie 💅

okay so picture this: you're deep in the kernel, you've got nothing but a u32 cache id, and you need to know what level that cache is at. that's the whole gig. this little icon does exactly that. ✨

🌸 SYNOPSIS 🌸

int find_acpi_cache_level_from_id (u32 cache_id );

🦋 ARGUMENTS 🦋

  • cache_id — the id field of the cache in question. that's it. that's the whole input. like handing someone your student ID and they somehow know your whole schedule. 🎀

💖 DESCRIPTION 💖

so what this does: it figures out the level of the cache identified by cache_id — and it's measured relative to any CPU, which is the slay part. it means you can still look up the property even when the CPUs themselves are offline. no CPUs? no problem, the answer's still there. 🫶

the level it hands back is lowkey useful for grouping caches that are peers — like, same level, same energy, bestie grouping. 👑

⚠️ heads up: the PPTT table must be rev 3 or later. no rev 3, no dice. periodt.
💀 also: if one CPU's L2 is shared with another CPU as L3? this function will return an unpredictable value. not wrong exactly — just unpredictable. which honestly is worse. don't say nobody warned you. 🙈

🔥 RETURN 🔥

  • -ENOENT — when the PPTT doesn't exist, the revision isn't supported, or the cache simply cannot be found. basically the "girl, i looked everywhere" error. 😭
  • otherwise — it returns a value representing the level of the specified cache. 🎉

🌈 SEE ALSO 🌈

here's the whole friend group, and yes they all talk to each other:

and that's the whole page, bestie — go forth and find those cache levels 💜

this one came out of ./drivers/acpi and it's stamped October 2026 — so if you're reading this, hi from the future, drink some water 🍓🧚

📦 where this page comes from