Go: x/sys/linux/perf: add package for Linux perf tracing

[the80srobot]

Linux ships with a robust suite of performance counters and samplers accessed via the perf_event_open system call.

Recent changes to x/sys/unix make it possible to call perf_event_open from Go, but using the perf events system correctly is notoriously hard.

Having recently implemented a wrapper for perf events in Go, I would like to generalize and contribute it upstream.

As regards the code location: x/sys/windows seems to have specialized subpackages, so maybe similar structure under x/sys/unix would work.

[ianlancetaylor]

Can you add an outline of the API? Thanks.

[aclements]

This would be wonderful, though getting the API right will be tricky.

If it's any help, I have an implementation of the perf events API for internal use in the runtime in CL 77651 and a more user-friendly API for reading perf.data files here. The latter doesn't support perf_event_open at the moment, but it has Go-friendly definitions of many of the perf API types.

Also relevant: #21295.

[minux]

If this is a Linux specific package, I'm wondering if we should start with
x/sys/linux/perf instead?
If there are perf counters in other UNIX flavors, we can consolidate them
into one API later into x/sys/unix/perf?

[pwaller]

FWIW, I have also hacked together some limited bindings for this purpose over at https://github.com/pwaller/perf. I'm fine with code and ideas being taken from there (or not). I make no claims as to the suitability of it for that purpose :). Agree with @minux in that it seems linux specific.

[rsc]

It sounds like people believe this would be worth having, especially since @the80srobot, @aclements, and @pwaller have essentially written three independent packages. It also sounds like the next step is to propose a specific API. Maybe those three people should hammer out what the right API is?

[bradfitz]

@ianlancetaylor and I think x/sys/linux/perf is probably a better home.

But sounds like nobody is opposed to this. Marking this Accepted. We can figure out API later.

[gopherbot]

Change https://golang.org/cl/160097 mentions this issue: linux/perf: API proposal

[acln0]

Hello. I have sent an API proposal in the hopes of moving this forward. Please take a look.

[acln0]

I have been working on this issue for the last couple of weeks. I have built a working perf package, which covers a large portion of the perf API surface. I'm going to abandon https://golang.org/cl/160097, and send a new CL, with working code, that can be tested and used.

I am hoping that a CL with actual documentation and working code might be easier to review and get feedback on than the previous API sketch. Please take a look.

Thanks,
Andrei

[gopherbot]

Change https://golang.org/cl/168059 mentions this issue: unix/linux/perf: new package

[hodgesds]

After also implementing yet another library my experience has been that it becomes extremely tricky to get meaningful data at the goroutine level due to the runtime (which is generally what everyone wants). Yes, you can call runtime.LockOSThread, but that doesn't work when your thread could get scheduled on a different core. You end up having to use unix.SchedSetaffinity to set the affinity of goroutine locked thread to a core. The configuration of the PerfEventAttr seems to be the most difficult thing to get right, but I'm interested to see where this goes.