tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Too many PMC implementations



Le 23/08/2018 à 17:47, Anders Magnusson a écrit :
Den 2018-08-23 kl. 17:03, skrev Maxime Villard:
Le 23/08/2018 à 16:28, Anders Magnusson a écrit :
Den 2018-08-23 kl. 15:53, skrev Maxime Villard:
Le 17/08/2018 à 17:42, Kamil Rytarowski a écrit :
On 17.08.2018 17:13, Maxime Villard wrote:
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.

Speaking realistically, probably all the recent software-based kernel
profiling was done with DTrace.

Yes. So I will proceed.

Note that the removal of the kernel gprof implies the removal of kgmon.
Just checking:  How will it work for ports like vax?
When searching for bottlenecks I normally use gprof/kgmon.  I don't know
anything about DTrace, hence the question.

It looks like there will be no replacement. Are you sure this is really
kgmon? Because as far as I can tell, in many architectures GPROF is just
dead code that either doesn't compile or doesn't have effect (missing
opt_gprof.h, but I did add it in February of this year in the MI parts,
so it was likely even more broken before).

I have used it not long ago for vax.  Maybe I did have to do some tweaks, do not
remember,
but I really want to be able to use kernel profiling on vax.

So, I really oppose removing it and leaving vax without any kernel profiling
choice.

Well I guess kgprof will have to stay then, along with gprof (the initial
conversation). We can still clean up the dead code in the other ports, but
the interest is rather limited and I don't think I'll bother.


Home | Main Index | Thread Index | Old Index