STRUCT CMBDATA(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… struct cmbdata(9) β€” a.k.a. the channel measurement block data for user space, bestie

okay so this is struct cmbdata(9) from the Kernel API Manual, and it's literally the channel measurement block data that gets handed over to user space. it's giving "backend metrics but make it s390" and honestly? iconic. let's get into it 🫢


✨ NAME ✨

struct cmbdata β€” channel measurement block data for user space. that's it, that's the whole vibe. it's the struct that carries your measurement numbers out to userspace so your programs can actually look at them πŸ’–


✨ SYNOPSIS ✨

here's the whole thing, no cap, every member in order:

struct cmbdata {
    __u64 size;
    __u64 elapsed_time;
    __u64 ssch_rsch_count;
    __u64 sample_count;
    __u64 device_connect_time;
    __u64 function_pending_time;
    __u64 device_disconnect_time;
    __u64 control_unit_queuing_time;
    __u64 device_active_only_time;
    __u64 device_busy_time;
    __u64 initial_command_response_time;
 };

🌸 Members 🌸

every single one of these is a __u64, and i need you to appreciate that. let's go member by member πŸ”₯

  • size β€” the size of the stored data, bestie. that's it, that's the whole field πŸ’…
  • elapsed_time β€” the time since the last sampling. like "how long has it been since we last checked in on you" energy ⏰
  • ssch_rsch_count β€” the number of ssch and rsch. both of them. counted together. slay 🌈
  • sample_count β€” the number of samples. the literal count of samples, we love a straightforward icon πŸ‘‘
  • device_connect_time β€” the time of device connect πŸ”Œ
  • function_pending_time β€” the time of function pending ⏳
  • device_disconnect_time β€” the time of device disconnect πŸ‘‹
  • control_unit_queuing_time β€” the time of control unit queuing. yes that's a whole mouthful, we still stan πŸŽ€
  • device_active_only_time β€” the time of device active only ✨
  • device_busy_time β€” the time of device busy, and this one's the ext. format flavor πŸ¦‹
  • initial_command_response_time β€” the initial command response time, also ext. format πŸ’œ

πŸ¦‹ Description πŸ¦‹

okay so here's the lore 🧚

All values are stored as 64 bit for simplicity, especially in 32 bit emulation mode. like, every single value. that's the design choice and honestly it ate β€” no fiddly widths to worry about when you're emulating 32 bit on a big machine πŸ’€

All time values are normalized to nanoseconds. so no matter what you're reading, the unit is nanoseconds, periodt ⭐

Currently, two formats are known, and they differ by the size of this structure. the important part: the last two members β€” device_busy_time and initial_command_response_time β€” are only set when the extended channel measurement facility is activated. that facility first shipped in z990 machines, so if you're on that, you're in the extended-format club πŸŽ€ otherwise those two are just... not set. vibes only 🌸

and here's the little heads-up: potentially, more fields could be added, which would result in a new ioctl number. so don't go assuming the struct is frozen forever, bestie β€” the format is versioned via that ioctl number for a reason πŸ™ˆ

πŸ’œ SEE ALSO πŸ’œ

  • Kernel file ./arch/s390/include/uapi/asm/cmb.h β€” go read it, iykyk πŸ“–

okay that's the whole page, you're officially caught up πŸ’– this little gem lives in ./arch/s390/include/uapi/asm and the page is dated October 2026 β€” so yeah, fresh from the future, highkey iconic, no notes 🌟 mwah, go measure some channels responsibly πŸ’…βœ¨

πŸ“¦ where this page comes from