Re: Too many PMC implementations

[Jason Thorpe <thorpej%me.com@localhost>]

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 <max%m00nbsd.net@localhost> 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