tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Too many PMC implementations
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
Home |
Main Index |
Thread Index |
Old Index