Re: Too many PMC implementations

[Maxime Villard <max%m00nbsd.net@localhost>]

Le 17/08/2018 à 16:43, Joerg Sonnenberger a écrit :
> On Fri, Aug 17, 2018 at 04:20:30PM +0200, Maxime Villard wrote:
> > So no one has any opinion on that? Because in this case I will remove it
> > soon. (Talking about the kernel gprof.)
>
> I'm quite reluctant to remove the only sample based profiler we have
> right now. Esp. since we don't have any infrastructure for counter-based
> profilers either AFAICT.

We do with tprof now, no?


Le 17/08/2018 à 16:50, Mouse a écrit :
> > > I agree that it would be better to retire gprof in base, because
> > > there are more powerful tools now, and also advanced hardware
> > > support (PMC, PEBS, ProcessorTrace).
>
> ...for ports that _have_ "advanced hardware support", maybe.  (And what
> are the "more powerful tools"?  I haven't been following the state of
> the art in open-source profiling tools.)

Yes, basically I was talking about x86. I do know that many architectures
support PMCs, but I don't know how precise the events are (etc). The tools
were mentioned before, like the linux "perf", which is pretty good.

Note that I'm talking about the kernel gprof, and not the userland gprof.
In terms of kernel profiling, it's not nonsensical to say that since we
support ARM and x86 in tprof, we can cover 99% of the MI parts of
whatever architecture. From then on, being able to profile the kernel on
other architectures has very little interest.

The gprof code is rather shitty and old, I dropped it from the x86 kernels
so it's not like I care a lot now, but since I saw the thread I thought I
would bring this up.