Hacker News Reader

Comment by gens | Hacker News Reader

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.

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.

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.

Reply on news.ycombinator.com