Seems ok. We do have many tools in this space: turbostat, i7z, tiptop, perf stat, pcm, pmu-tools, etc. So I kinda wish these tool authors would solve the missing metrics rather than reinventing existing ones. Many tools that kinda do the same thing is a problem in tech - it costs us time to dig through them.

I've said it before in talks, but if you want to write a new tool in this space, please write bustop - top for system busses.

(I'd also rather this tool didn't use a kernel module, of course, and I still don't understand why it needs to).

That GIF makes me wonder. It's showing different threads of a single core at different frequencies which is impossible. And didn't Nehalem run all the cores at the same frequency as well? Perhaps that effect is caused by sampling error or it's measuring something other than the actual ratio.

It represents an average, of clocks per sample. For example when in the C3 to C6 states, the clock is stopped so would be effectively zero during those tiny periods.

For Intel processors, on Linux, the "turbostat" utility provides much of the same information using the -d switch.

As does cpufreq-aperf (some of the same stats, at least)

i'm sure it's been vetted but i don't feel all that great loading a module into my kernel just to check on my cpu metrics, although the IPC numbers are rather cool.

Why does it need a kernel module ?

I was wondering the same. No way I would load a module just to monitor CPU.

FreeBSD already comes with cpuctl.ko which is used by Intel's pcm.x tools. No way Linux doesn't have something similar…

Linux has MSR module or one can use perf.

Maybe for the real-time cache usage display ? Or performance (in the sense of less noise while measuring) ?

I'm tempted to try it out and see for myself, though.

For posterity; Cpu counters for a lot of things can be gotten from userspace. The linux kernel exposes a lot of things in /proc (procfs) and /sys (sysfs). Programs like perf, slabtop (and probably others, that i can't remember now), use these informations to display more-or-less the same data as this program.

That's literally the second thing in the README after the fancy GIF.

Yes, i read it.

Most of the things listed there can be gotten from userspace (through cpu instructions/registers, procfs, sysfs).

Do you know which one of those things can not be gotten in userspace ? Turbo boost state ? Topology ?

PCM is similar and is userspace. However on OSX, you need a driver and then various other hoops must be jumped in order to enable it. On Linux, I think it just runs out of the box. But in any case, PCM itself is userspace.

https://github.com/opcm/pcm

There are generic tools for these stuff on linux like perf, powertop, slabtop, lm-sensors, and probably more that idk about.

This PCM looks like it provides information that the tools above can't, like pcm and memory bandwidths (unless i misunderstood what it does). Sucks that it's intel only, i'd like to watch memory bandwidth usage on my amd. Unrelated: this reminds me of mcelog, that collects hardware errors.

The author is probably concerned about the overhead of using N system calls to read N MSRs.

It would be cool if eBPF could read MSRs; then this kind of monitoring could be done though perf tracing.

RDMSR is an instruction, not a syscall. It's not clear to me either why this needs a kernel module. It's similar to i7z, which from memory does not use it's own kernel module.

eBPF can read the relevant PMCs as of Linux 4.9. eg, the llcstat tool in bcc does this. (It was something I pushed for, and Alexei delivered)

You already know this, but for completeness you can't RDMSR from userspace, so to read MSRs you can use the msr kernel module which requires 2 system calls per MSR (which is what i7z does) or you can write your own kernel module which requires fewer system calls. Clearly a lot of people in this thread disagree with the author's decision.

Can eBPF read non-PMC registers like IA32_PERF_STATUS? I'm not getting much by googling.

Thanks for all your work on this topic; it's really educational.

Thank you Brendan to comment this post, i guess Cyril(the main author) will be happy. We successfully compile it on 2.6.32 kernel on production servers for exemple. We needed to compile gcc >5 to fully make it runs, as far as the RHEL6.5 default gcc is 4.4.

So talking about what 4.9 kernel can bring is interesting, but not everybody runs this version of kernel.

Well using perf or reading MSR doesn't need you writing your kernel module. I think the overhead of using perf or direct access to MSR are kinda similar.

My thought exactly.

It looked really nice, but I do not need that data bad enough to load a third-party kernel module. Or mess with my grub configuration.

it tested it, it works fine