Speaking as someone who was peripherally involved in the PMC flavor below, I have no objections to this.
> On Jul 11, 2018, at 9:22 AM, Maxime Villard <m...@m00nbsd.net> wrote: > > Right now we have three (or more?) different implementations for Performance > Monitoring Counters: > > * PMC: this one is MI. It is used only on one ARM model (xscale I think). > There used to be an x86 code for it, but it was broken, and I removed it. > The implementation comes with libpmc, a library we provide. The code > hasn't moved these last 15 years. I don't like this implementation, it is > really invasive (see the numerous pmc.h files that are all empty). > > * X86PMC: this one is MD, and only available for x86. I wrote it myself. > The code is small (x86/pmc.c), and functional. The PMCs are system-wide, > and retrieved on a per-cpu basis. But this implementation does not > support tracking, that is, we get numbers (about the cache misses for > example), but we don't know where they happened. > > * TPROF: this one is MI, but only x86 support is present. TPROF provides > the backend needed to support tracking: via a device, that userland can > read from, in order to absorb the event samples produced by the kernel. > The backend is pretty good, but the frontend (where the user chooses > which PMC etc) is inexistent - the CPU/event detection is not there > either. The backend is MI (/dev/tprof/tprof.c), and can be used on other > architectures. The module already exists to dynamically modload. > > I think it would be good to: > > * Remove PMC entirely. Then remove libpmc too. > > * Merge X86PMC into the x86 part of TPROF. That is to say, into > x86/tprof_*. Then remove X86PMC. > > * Later, maybe, someone will want to add other architectures in TPROF, like > all the recent ARMs. > > Maxime -- thorpej