Den 2018-08-23 kl. 16:48, skrev Kamil Rytarowski:
On 23.08.2018 16:28, Anders Magnusson wrote:
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.
-- Ragge
There is no support of DTrace for vax and probably there won't be one.
Also probably DTrace is not a final solution per se (DTrace is described
as step backwards by people such as Brendan Gregg).. but we are working
on better toolchain support to open more possibilities such as XRay.
Regarding vax there might be bottlenecks in MD code, but DTrace is a
decent one for MI code on supported ports.
Hm, so this means that we will be without kernel profiling support at
all on non-DTrace architectures?
I'm not too happy about that by obvious reasons.
It do not work to profile code paths on other architectures, since what
takes time is very different.
And yes, it is not the MD code that is the case, it's the MI code.
I may have missed something, but why remove something that works without
replacing it with something new?
Only have profiling on a few ports do not sound very clever to me.
-- Ragge