domain_setup_l3_mon_state(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… domain_setup_l3_mon_state(9) πŸ’…

okay so bestie, welcome to the Kernel API Manual ✨ β€” yes this is a kernel manpage, yes it's section 9, and yes we're gonna make it make sense. this one's about domain_setup_l3_mon_state, and it's honestly giving "small function, big responsibilities" πŸŽ€


✨ NAME ✨

domain_setup_l3_mon_state β€” literally just initialising the domain monitoring structures. that's the whole job. no cap. πŸ’–


🌸 SYNOPSIS 🌸

int domain_setup_l3_mon_state (struct rdt_resource *r , struct
       rdt_l3_mon_domain *d );

that's it, that's the whole signature 🫢


πŸ¦‹ ARGUMENTS πŸ¦‹

  • r β€” the resource that belongs to the newly online domain. the resource. for the domain. the new one. πŸ’«
  • d β€” the newly online domain itself. hi bestie, welcome online πŸ‘‘βœ¨

πŸŽ€ DESCRIPTION πŸŽ€

okay so here's the tea: this function allocates the monitor resources that belong to this domain. that's the whole vibe check.

it gets called when the first CPU of a domain comes online β€” and here's the iconic part β€” regardless of whether the filesystem is mounted 😭 like, mounted or not, it's showing up. main character energy fr fr.

during boot, this may get called before the global allocations have been made by resctrl_l3_mon_resource_init. so yeah, sometimes it runs early to the party, before the party's even set up πŸ™ˆ

it's also called during CPU online, which may run as soon as the CPU online callbacks are set up during resctrl initialization. and the number of supported RMIDs may be reduced if additional mon_capable resources are enumerated at mount time. which means β€” and this is the important bit, don't skip it β€” the rdt_l3_mon_domain::mbm_states[] and rdt_l3_mon_domain::rmid_busy_llc allocations may be larger than needed 🫠 not a bug, just a little extra. slay.


🧚 RETURN 🧚

  • 0 for success πŸ’–
  • -ENOMEM when the memory said no πŸ’€

🌈 SEE ALSO 🌈

the kernel file ./fs/resctrl/rdtgroup.c and its whole friend group β€” no literally, all of them, we're not leaving anyone out:


also lowkey a heads-up: the mbm_states[] and rmid_busy_llc allocations can end up bigger than they need to be. that's documented behaviour, not a glitch, so don't come for it πŸ’…

and that's the whole page bestie 🫢 it's from ./fs/resctrl, dated October 2026, and it's genuinely iconic that you read all the way to the end of a section 9 manpage β€” obsessed, honestly πŸŽ€πŸ’–βœ¨

πŸ“¦ where this page comes from