User: Password:
|
|
Subscribe / Log in / New account

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 (guest, #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 (guest, #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:
http://code.google.com/p/jrfonseca/wiki/Gprof2Dot

Several tools have also their similar callgraph visualizers, for example:

* Google's perftools:
http://code.google.com/p/gperftools/wiki/GooglePerformanc...

* sp-rtrace:
http://harmattan-dev.nokia.com/docs/library/html/guide/ht...
http://maemo.gitorious.org/maemo-tools/sp-rtrace/

And there's also a nice viewer for dot graphs which doesn't require converting them first to SVG etc:
http://code.google.com/p/jrfonseca/wiki/XDot


Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds