Weekly Edition
Return to the Kernel page
| |||||||||||||
Gregg: Linux Kernel Performance: Flame Graphs
Brendan Gregg demonstrates
"flame graphs" as a tool for tracking down kernel performance
problems. "The perf report tree (and the ncurses navigator) do an
excellent job at presenting this information as text. However, with text
there are limitations. The output often does not fit in one screen (you
could say it doesn’t need to, if the bulk of the samples are identified on
the first page). Also, identifying the hottest code paths requires reading
the percentages. With the flame graph, all the data is on screen at once,
and the hottest code-paths are immediately obvious as the widest
functions." The flame graph code is
hosted on Github.
(Log in to post comments)
Gregg: Linux Kernel Performance: Flame Graphs Posted Mar 17, 2012 20:28 UTC (Sat) by hmh (subscriber, #3838) [Link]
kcachegrind has a view mode for valgrind profile data that uses a similar concept as flame graphs, but quite a different visualization:
http://kcachegrind.sourceforge.net/html/CalleeMap.html
Gregg: Linux Kernel Performance: Flame Graphs Posted Mar 17, 2012 21:07 UTC (Sat) by JoeBuck (subscriber, #2330) [Link] Yes, I've use kcachegrind, and that visualization doesn't strike me as nearly as intuitive as flame graphs at least for some problems. It would be great to have a callgrind to flame graph converter. One issue is that the valgrind tools keep track only of a limited stack depth, and flame graphs are based on the whole stack, but callgrind could be given a very large --num-callers value.
Gregg: Linux Kernel Performance: Flame Graphs Posted Mar 19, 2012 21:43 UTC (Mon) by oak (subscriber, #2786) [Link]
From the article:
"The perf report tree (and the ncurses navigator) do an excellent job at presenting this information as text. However, with text there are limitations. The output often does not fit in one screen (you could say it doesn’t need to, if the bulk of the samples are identified on the first page). Also, identifying the hottest code paths requires reading the percentages."
Why one would do callgraphs as text instead of outputting a .dot file for GraphViz with node coloring to highlight the hotpaths?
Here's one such script that supports output from multiple different profilers:
Several tools have also their similar callgraph visualizers, for example:
* Google's perftools:
* sp-rtrace:
And there's also a nice viewer for dot graphs which doesn't require converting them first to SVG etc:
|
|||||||||||||