* "perf top -g" leaking ~300MB per second. @ 2014-12-13 8:48 Markus Trippelsdorf 2014-12-13 9:03 ` Markus Trippelsdorf 0 siblings, 1 reply; 9+ messages in thread From: Markus Trippelsdorf @ 2014-12-13 8:48 UTC (permalink / raw) To: linux-kernel Cc: Peter Zijlstra, Paul Mackerras, Ingo Molnar, Arnaldo Carvalho de Melo Running "perf top -g" built from current Linus tree apparently leaks ~300MB of memory every second an my machine. -- Markus ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: "perf top -g" leaking ~300MB per second. 2014-12-13 8:48 "perf top -g" leaking ~300MB per second Markus Trippelsdorf @ 2014-12-13 9:03 ` Markus Trippelsdorf 2014-12-13 15:26 ` Arnaldo Carvalho de Melo 0 siblings, 1 reply; 9+ messages in thread From: Markus Trippelsdorf @ 2014-12-13 9:03 UTC (permalink / raw) To: linux-kernel Cc: Peter Zijlstra, Paul Mackerras, Ingo Molnar, Arnaldo Carvalho de Melo On 2014.12.13 at 09:48 +0100, Markus Trippelsdorf wrote: > Running "perf top -g" built from current Linus tree apparently leaks > ~300MB of memory every second an my machine. Hmm, this is a much older problem. I just noticed this the first time today. To reproduce: Compile some application in the background (make -j4 in my case) and run "perf top -g". Perf will continue to accumulate memory until the system starts to swap and the OOM killer eventually kicks in. -- Markus ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: "perf top -g" leaking ~300MB per second. 2014-12-13 9:03 ` Markus Trippelsdorf @ 2014-12-13 15:26 ` Arnaldo Carvalho de Melo 2014-12-13 18:16 ` David Ahern 0 siblings, 1 reply; 9+ messages in thread From: Arnaldo Carvalho de Melo @ 2014-12-13 15:26 UTC (permalink / raw) To: Markus Trippelsdorf Cc: linux-kernel, Peter Zijlstra, Paul Mackerras, Ingo Molnar Em Sat, Dec 13, 2014 at 10:03:31AM +0100, Markus Trippelsdorf escreveu: > On 2014.12.13 at 09:48 +0100, Markus Trippelsdorf wrote: > > Running "perf top -g" built from current Linus tree apparently leaks > > ~300MB of memory every second an my machine. > > Hmm, this is a much older problem. I just noticed this the first time > today. > To reproduce: Compile some application in the background (make -j4 in my > case) and run "perf top -g". Perf will continue to accumulate memory > until the system starts to swap and the OOM killer eventually kicks in. Yeap, longstanding problem, try minimizing the problem using a lower frequency. The callchain code was done initially for 'report' and when I made 'top' reuse the hist_entry code allowing 'top' to collect callchains was too easy, but then we need to go thru the callchain/hists/hist_entry code to make sure that they don't leak, will try to do it... - Arnaldo ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: "perf top -g" leaking ~300MB per second. 2014-12-13 15:26 ` Arnaldo Carvalho de Melo @ 2014-12-13 18:16 ` David Ahern 2014-12-30 5:38 ` Namhyung Kim 0 siblings, 1 reply; 9+ messages in thread From: David Ahern @ 2014-12-13 18:16 UTC (permalink / raw) To: Arnaldo Carvalho de Melo, Markus Trippelsdorf Cc: linux-kernel, Peter Zijlstra, Paul Mackerras, Ingo Molnar On 12/13/14 8:26 AM, Arnaldo Carvalho de Melo wrote: > The callchain code was done initially for 'report' and when I made 'top' > reuse the hist_entry code allowing 'top' to collect callchains was too > easy, but then we need to go thru the callchain/hists/hist_entry code to > make sure that they don't leak, will try to do it... > As I recall it is build up of the dead_threads list. David ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: "perf top -g" leaking ~300MB per second. 2014-12-13 18:16 ` David Ahern @ 2014-12-30 5:38 ` Namhyung Kim 2014-12-30 8:35 ` Markus Trippelsdorf ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Namhyung Kim @ 2014-12-30 5:38 UTC (permalink / raw) To: David Ahern Cc: Arnaldo Carvalho de Melo, Markus Trippelsdorf, linux-kernel, Peter Zijlstra, Paul Mackerras, Ingo Molnar Hi David and Markus, On Sat, Dec 13, 2014 at 11:16:43AM -0700, David Ahern wrote: > On 12/13/14 8:26 AM, Arnaldo Carvalho de Melo wrote: > >The callchain code was done initially for 'report' and when I made 'top' > >reuse the hist_entry code allowing 'top' to collect callchains was too > >easy, but then we need to go thru the callchain/hists/hist_entry code to > >make sure that they don't leak, will try to do it... > > > > As I recall it is build up of the dead_threads list. Maybe. But I guess it's because of leak of callchains.. Markus, could you please test below patch how much it affects? >From b29ccd79727654653986ab1170e0b1f5d6518035 Mon Sep 17 00:00:00 2001 From: Namhyung Kim <namhyung@kernel.org> Date: Tue, 30 Dec 2014 14:28:45 +0900 Subject: [PATCH] perf callchain: Free callchains when hist entries are deleted Markus reported that "perf top -g" can leak ~300MB per second on his machine. This is partly because it missed to free callchains when hist entries are deleted. Fix it. Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de> Cc: Frederic Weisbecker <fweisbec@gmail.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org> --- tools/perf/util/callchain.c | 30 ++++++++++++++++++++++++++++++ tools/perf/util/callchain.h | 2 ++ tools/perf/util/hist.c | 1 + 3 files changed, 33 insertions(+) diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c index 64b377e591e4..14e7a123d43b 100644 --- a/tools/perf/util/callchain.c +++ b/tools/perf/util/callchain.c @@ -841,3 +841,33 @@ char *callchain_list__sym_name(struct callchain_list *cl, return bf; } + +static void free_callchain_node(struct callchain_node *node) +{ + struct callchain_list *list, *tmp; + struct callchain_node *child; + struct rb_node *n; + + list_for_each_entry_safe(list, tmp, &node->val, list) { + list_del(&list->list); + free(list); + } + + n = rb_first(&node->rb_root_in); + while (n) { + child = container_of(n, struct callchain_node, rb_node_in); + n = rb_next(n); + rb_erase(&child->rb_node_in, &node->rb_root_in); + + free_callchain_node(child); + free(child); + } +} + +void free_callchain(struct callchain_root *root) +{ + if (!symbol_conf.use_callchain) + return; + + free_callchain_node(&root->node); +} diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h index dbc08cf5f970..c0ec1acc38e4 100644 --- a/tools/perf/util/callchain.h +++ b/tools/perf/util/callchain.h @@ -198,4 +198,6 @@ static inline int arch_skip_callchain_idx(struct thread *thread __maybe_unused, char *callchain_list__sym_name(struct callchain_list *cl, char *bf, size_t bfsize, bool show_dso); +void free_callchain(struct callchain_root *root); + #endif /* __PERF_CALLCHAIN_H */ diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c index 30ff2cb92884..e17163fcb702 100644 --- a/tools/perf/util/hist.c +++ b/tools/perf/util/hist.c @@ -945,6 +945,7 @@ void hist_entry__delete(struct hist_entry *he) zfree(&he->mem_info); zfree(&he->stat_acc); free_srcline(he->srcline); + free_callchain(he->callchain); free(he); } -- 2.1.3 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: "perf top -g" leaking ~300MB per second. 2014-12-30 5:38 ` Namhyung Kim @ 2014-12-30 8:35 ` Markus Trippelsdorf 2014-12-30 23:04 ` Arnaldo Carvalho de Melo 2015-01-08 15:09 ` Arnaldo Carvalho de Melo 2015-01-09 12:31 ` [tip:perf/urgent] perf callchain: Free callchains when hist entries are deleted tip-bot for Namhyung Kim 2 siblings, 1 reply; 9+ messages in thread From: Markus Trippelsdorf @ 2014-12-30 8:35 UTC (permalink / raw) To: Namhyung Kim Cc: David Ahern, Arnaldo Carvalho de Melo, linux-kernel, Peter Zijlstra, Paul Mackerras, Ingo Molnar On 2014.12.30 at 14:38 +0900, Namhyung Kim wrote: > Hi David and Markus, > > On Sat, Dec 13, 2014 at 11:16:43AM -0700, David Ahern wrote: > > On 12/13/14 8:26 AM, Arnaldo Carvalho de Melo wrote: > > >The callchain code was done initially for 'report' and when I made 'top' > > >reuse the hist_entry code allowing 'top' to collect callchains was too > > >easy, but then we need to go thru the callchain/hists/hist_entry code to > > >make sure that they don't leak, will try to do it... > > > > > > > As I recall it is build up of the dead_threads list. > > Maybe. But I guess it's because of leak of callchains.. > > Markus, could you please test below patch how much it affects? Thanks Namhyung. It leaks an order of magnitude less memory now: ~30MB/sec on my machine. Valgrind shows (last entries of the list): ... ==20512== 7,225,920 bytes in 17,370 blocks are possibly lost in loss record 295 of 301 ==20512== at 0x402B000: calloc (vg_replace_malloc.c:623) ==20512== by 0x4A6996: zalloc (util.h:189) ==20512== by 0x4A6996: hist_entry__new (hist.c:309) ==20512== by 0x4A8249: add_hist_entry (hist.c:431) ==20512== by 0x4A8249: __hists__add_entry (hist.c:477) ==20512== by 0x4A8902: iter_add_single_cumulative_entry (hist.c:730) ==20512== by 0x4A8A64: hist_entry_iter__add (hist.c:876) ==20512== by 0x43787A: perf_event__process_sample (builtin-top.c:787) ==20512== by 0x43787A: perf_top__mmap_read_idx (builtin-top.c:854) ==20512== by 0x4395EE: perf_top__mmap_read (builtin-top.c:871) ==20512== by 0x4395EE: __cmd_top (builtin-top.c:974) ==20512== by 0x4395EE: cmd_top (builtin-top.c:1266) ==20512== by 0x41B702: run_builtin (perf.c:341) ==20512== by 0x41AE51: handle_internal_command (perf.c:400) ==20512== by 0x41AE51: run_argv (perf.c:444) ==20512== by 0x41AE51: main (perf.c:559) ==20512== ==20512== 8,922,480 bytes in 159,330 blocks are possibly lost in loss record 296 of 301 ==20512== at 0x402B000: calloc (vg_replace_malloc.c:623) ==20512== by 0x4821FE: zalloc (util.h:189) ==20512== by 0x4821FE: fill_node (callchain.c:450) ==20512== by 0x4821FE: add_child (callchain.c:473) ==20512== by 0x4821FE: append_chain_children (callchain.c:596) ==20512== by 0x48514E: callchain_append (callchain.c:672) ==20512== by 0x4A8947: iter_add_single_cumulative_entry (hist.c:739) ==20512== by 0x4A8A64: hist_entry_iter__add (hist.c:876) ==20512== by 0x43787A: perf_event__process_sample (builtin-top.c:787) ==20512== by 0x43787A: perf_top__mmap_read_idx (builtin-top.c:854) ==20512== by 0x43967E: perf_top__mmap_read (builtin-top.c:871) ==20512== by 0x43967E: __cmd_top (builtin-top.c:996) ==20512== by 0x43967E: cmd_top (builtin-top.c:1266) ==20512== by 0x41B702: run_builtin (perf.c:341) ==20512== by 0x41AE51: handle_internal_command (perf.c:400) ==20512== by 0x41AE51: run_argv (perf.c:444) ==20512== by 0x41AE51: main (perf.c:559) ==20512== ==20512== 11,050,136 bytes in 1,663 blocks are definitely lost in loss record 297 of 301 ==20512== at 0x402B000: calloc (vg_replace_malloc.c:623) ==20512== by 0x44F7BF: zalloc (util.h:189) ==20512== by 0x44F7BF: symbol__alloc_hist (annotate.c:455) ==20512== by 0x44F7BF: symbol__inc_addr_samples (annotate.c:507) ==20512== by 0x44F7BF: hist_entry__inc_addr_samples (annotate.c:521) ==20512== by 0x437A65: perf_top__record_precise_ip (builtin-top.c:195) ==20512== by 0x437A65: hist_iter__top_callback (builtin-top.c:688) ==20512== by 0x4A8AC8: hist_entry_iter__add (hist.c:892) ==20512== by 0x43787A: perf_event__process_sample (builtin-top.c:787) ==20512== by 0x43787A: perf_top__mmap_read_idx (builtin-top.c:854) ==20512== by 0x43967E: perf_top__mmap_read (builtin-top.c:871) ==20512== by 0x43967E: __cmd_top (builtin-top.c:996) ==20512== by 0x43967E: cmd_top (builtin-top.c:1266) ==20512== by 0x41B702: run_builtin (perf.c:341) ==20512== by 0x41AE51: handle_internal_command (perf.c:400) ==20512== by 0x41AE51: run_argv (perf.c:444) ==20512== by 0x41AE51: main (perf.c:559) ==20512== ==20512== 24,920,064 bytes in 59,904 blocks are possibly lost in loss record 298 of 301 ==20512== at 0x402B000: calloc (vg_replace_malloc.c:623) ==20512== by 0x4A6996: zalloc (util.h:189) ==20512== by 0x4A6996: hist_entry__new (hist.c:309) ==20512== by 0x4A8249: add_hist_entry (hist.c:431) ==20512== by 0x4A8249: __hists__add_entry (hist.c:477) ==20512== by 0x4A8902: iter_add_single_cumulative_entry (hist.c:730) ==20512== by 0x4A8A64: hist_entry_iter__add (hist.c:876) ==20512== by 0x43787A: perf_event__process_sample (builtin-top.c:787) ==20512== by 0x43787A: perf_top__mmap_read_idx (builtin-top.c:854) ==20512== by 0x43967E: perf_top__mmap_read (builtin-top.c:871) ==20512== by 0x43967E: __cmd_top (builtin-top.c:996) ==20512== by 0x43967E: cmd_top (builtin-top.c:1266) ==20512== by 0x41B702: run_builtin (perf.c:341) ==20512== by 0x41AE51: handle_internal_command (perf.c:400) ==20512== by 0x41AE51: run_argv (perf.c:444) ==20512== by 0x41AE51: main (perf.c:559) ==20512== ==20512== 26,147,680 bytes in 62,855 blocks are possibly lost in loss record 299 of 301 ==20512== at 0x402B000: calloc (vg_replace_malloc.c:623) ==20512== by 0x4A6996: zalloc (util.h:189) ==20512== by 0x4A6996: hist_entry__new (hist.c:309) ==20512== by 0x4A8249: add_hist_entry (hist.c:431) ==20512== by 0x4A8249: __hists__add_entry (hist.c:477) ==20512== by 0x4A8728: iter_add_next_cumulative_entry (hist.c:803) ==20512== by 0x4A8AA5: hist_entry_iter__add (hist.c:887) ==20512== by 0x43787A: perf_event__process_sample (builtin-top.c:787) ==20512== by 0x43787A: perf_top__mmap_read_idx (builtin-top.c:854) ==20512== by 0x43967E: perf_top__mmap_read (builtin-top.c:871) ==20512== by 0x43967E: __cmd_top (builtin-top.c:996) ==20512== by 0x43967E: cmd_top (builtin-top.c:1266) ==20512== by 0x41B702: run_builtin (perf.c:341) ==20512== by 0x41AE51: handle_internal_command (perf.c:400) ==20512== by 0x41AE51: run_argv (perf.c:444) ==20512== by 0x41AE51: main (perf.c:559) ==20512== ==20512== 44,939,792 bytes in 3,788 blocks are definitely lost in loss record 300 of 301 ==20512== at 0x402B000: calloc (vg_replace_malloc.c:623) ==20512== by 0x44F7BF: zalloc (util.h:189) ==20512== by 0x44F7BF: symbol__alloc_hist (annotate.c:455) ==20512== by 0x44F7BF: symbol__inc_addr_samples (annotate.c:507) ==20512== by 0x44F7BF: hist_entry__inc_addr_samples (annotate.c:521) ==20512== by 0x437A65: perf_top__record_precise_ip (builtin-top.c:195) ==20512== by 0x437A65: hist_iter__top_callback (builtin-top.c:688) ==20512== by 0x4A8AC8: hist_entry_iter__add (hist.c:892) ==20512== by 0x43787A: perf_event__process_sample (builtin-top.c:787) ==20512== by 0x43787A: perf_top__mmap_read_idx (builtin-top.c:854) ==20512== by 0x4395EE: perf_top__mmap_read (builtin-top.c:871) ==20512== by 0x4395EE: __cmd_top (builtin-top.c:974) ==20512== by 0x4395EE: cmd_top (builtin-top.c:1266) ==20512== by 0x41B702: run_builtin (perf.c:341) ==20512== by 0x41AE51: handle_internal_command (perf.c:400) ==20512== by 0x41AE51: run_argv (perf.c:444) ==20512== by 0x41AE51: main (perf.c:559) ==20512== ==20512== 81,248,440 bytes in 1,450,865 blocks are possibly lost in loss record 301 of 301 ==20512== at 0x402B000: calloc (vg_replace_malloc.c:623) ==20512== by 0x4821FE: zalloc (util.h:189) ==20512== by 0x4821FE: fill_node (callchain.c:450) ==20512== by 0x4821FE: add_child (callchain.c:473) ==20512== by 0x4821FE: append_chain_children (callchain.c:596) ==20512== by 0x48514E: callchain_append (callchain.c:672) ==20512== by 0x4A8768: iter_add_next_cumulative_entry (hist.c:812) ==20512== by 0x4A8AA5: hist_entry_iter__add (hist.c:887) ==20512== by 0x43787A: perf_event__process_sample (builtin-top.c:787) ==20512== by 0x43787A: perf_top__mmap_read_idx (builtin-top.c:854) ==20512== by 0x43967E: perf_top__mmap_read (builtin-top.c:871) ==20512== by 0x43967E: __cmd_top (builtin-top.c:996) ==20512== by 0x43967E: cmd_top (builtin-top.c:1266) ==20512== by 0x41B702: run_builtin (perf.c:341) ==20512== by 0x41AE51: handle_internal_command (perf.c:400) ==20512== by 0x41AE51: run_argv (perf.c:444) ==20512== by 0x41AE51: main (perf.c:559) ==20512== ==20512== LEAK SUMMARY: ==20512== definitely lost: 56,810,427 bytes in 5,479 blocks ==20512== indirectly lost: 4,000 bytes in 125 blocks ==20512== possibly lost: 210,493,048 bytes in 2,552,578 blocks ==20512== still reachable: 18,258 bytes in 242 blocks ==20512== suppressed: 0 bytes in 0 blocks -- Markus ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: "perf top -g" leaking ~300MB per second. 2014-12-30 8:35 ` Markus Trippelsdorf @ 2014-12-30 23:04 ` Arnaldo Carvalho de Melo 0 siblings, 0 replies; 9+ messages in thread From: Arnaldo Carvalho de Melo @ 2014-12-30 23:04 UTC (permalink / raw) To: Markus Trippelsdorf Cc: Namhyung Kim, David Ahern, linux-kernel, Peter Zijlstra, Paul Mackerras, Ingo Molnar Em Tue, Dec 30, 2014 at 09:35:24AM +0100, Markus Trippelsdorf escreveu: > On 2014.12.30 at 14:38 +0900, Namhyung Kim wrote: > > Hi David and Markus, > > > > On Sat, Dec 13, 2014 at 11:16:43AM -0700, David Ahern wrote: > > > On 12/13/14 8:26 AM, Arnaldo Carvalho de Melo wrote: > > > >The callchain code was done initially for 'report' and when I made 'top' > > > >reuse the hist_entry code allowing 'top' to collect callchains was too > > > >easy, but then we need to go thru the callchain/hists/hist_entry code to > > > >make sure that they don't leak, will try to do it... > > > > > > > > > > As I recall it is build up of the dead_threads list. > > > > Maybe. But I guess it's because of leak of callchains.. > > > > Markus, could you please test below patch how much it affects? > > Thanks Namhyung. It leaks an order of magnitude less memory now: > ~30MB/sec on my machine. > > Valgrind shows (last entries of the list): > ... > ==20512== 7,225,920 bytes in 17,370 blocks are possibly lost in loss record 295 of 301 > ==20512== at 0x402B000: calloc (vg_replace_malloc.c:623) > ==20512== by 0x4A6996: zalloc (util.h:189) > ==20512== by 0x4A6996: hist_entry__new (hist.c:309) > ==20512== by 0x4A8249: add_hist_entry (hist.c:431) > ==20512== by 0x4A8249: __hists__add_entry (hist.c:477) > ==20512== by 0x4A8902: iter_add_single_cumulative_entry (hist.c:730) > ==20512== by 0x4A8A64: hist_entry_iter__add (hist.c:876) > ==20512== by 0x43787A: perf_event__process_sample (builtin-top.c:787) > ==20512== by 0x43787A: perf_top__mmap_read_idx (builtin-top.c:854) > ==20512== by 0x4395EE: perf_top__mmap_read (builtin-top.c:871) > ==20512== by 0x4395EE: __cmd_top (builtin-top.c:974) > ==20512== by 0x4395EE: cmd_top (builtin-top.c:1266) > ==20512== by 0x41B702: run_builtin (perf.c:341) > ==20512== by 0x41AE51: handle_internal_command (perf.c:400) > ==20512== by 0x41AE51: run_argv (perf.c:444) > ==20512== by 0x41AE51: main (perf.c:559) #1) Ok, those are the hist_entries that were not decayed, if top continued they would eventually be decayed, freed, etc, i.e. the exit of top is equivalent to the last decay. > ==20512== > ==20512== 8,922,480 bytes in 159,330 blocks are possibly lost in loss record 296 of 301 > ==20512== at 0x402B000: calloc (vg_replace_malloc.c:623) > ==20512== by 0x4821FE: zalloc (util.h:189) > ==20512== by 0x4821FE: fill_node (callchain.c:450) > ==20512== by 0x4821FE: add_child (callchain.c:473) > ==20512== by 0x4821FE: append_chain_children (callchain.c:596) > ==20512== by 0x48514E: callchain_append (callchain.c:672) > ==20512== by 0x4A8947: iter_add_single_cumulative_entry (hist.c:739) > ==20512== by 0x4A8A64: hist_entry_iter__add (hist.c:876) > ==20512== by 0x43787A: perf_event__process_sample (builtin-top.c:787) > ==20512== by 0x43787A: perf_top__mmap_read_idx (builtin-top.c:854) > ==20512== by 0x43967E: perf_top__mmap_read (builtin-top.c:871) > ==20512== by 0x43967E: __cmd_top (builtin-top.c:996) > ==20512== by 0x43967E: cmd_top (builtin-top.c:1266) > ==20512== by 0x41B702: run_builtin (perf.c:341) > ==20512== by 0x41AE51: handle_internal_command (perf.c:400) > ==20512== by 0x41AE51: run_argv (perf.c:444) > ==20512== by 0x41AE51: main (perf.c:559) > ==20512== > ==20512== 11,050,136 bytes in 1,663 blocks are definitely lost in loss record 297 of 301 > ==20512== at 0x402B000: calloc (vg_replace_malloc.c:623) > ==20512== by 0x44F7BF: zalloc (util.h:189) > ==20512== by 0x44F7BF: symbol__alloc_hist (annotate.c:455) > ==20512== by 0x44F7BF: symbol__inc_addr_samples (annotate.c:507) > ==20512== by 0x44F7BF: hist_entry__inc_addr_samples (annotate.c:521) > ==20512== by 0x437A65: perf_top__record_precise_ip (builtin-top.c:195) > ==20512== by 0x437A65: hist_iter__top_callback (builtin-top.c:688) > ==20512== by 0x4A8AC8: hist_entry_iter__add (hist.c:892) > ==20512== by 0x43787A: perf_event__process_sample (builtin-top.c:787) > ==20512== by 0x43787A: perf_top__mmap_read_idx (builtin-top.c:854) > ==20512== by 0x43967E: perf_top__mmap_read (builtin-top.c:871) > ==20512== by 0x43967E: __cmd_top (builtin-top.c:996) > ==20512== by 0x43967E: cmd_top (builtin-top.c:1266) > ==20512== by 0x41B702: run_builtin (perf.c:341) > ==20512== by 0x41AE51: handle_internal_command (perf.c:400) > ==20512== by 0x41AE51: run_argv (perf.c:444) > ==20512== by 0x41AE51: main (perf.c:559) These (symbol__alloc_hist) we need to free up the decaying of per RIP annotation gets to zero... Will check where to do this... > ==20512== > ==20512== 24,920,064 bytes in 59,904 blocks are possibly lost in loss record 298 of 301 > ==20512== at 0x402B000: calloc (vg_replace_malloc.c:623) > ==20512== by 0x4A6996: zalloc (util.h:189) > ==20512== by 0x4A6996: hist_entry__new (hist.c:309) > ==20512== by 0x4A8249: add_hist_entry (hist.c:431) > ==20512== by 0x4A8249: __hists__add_entry (hist.c:477) > ==20512== by 0x4A8902: iter_add_single_cumulative_entry (hist.c:730) > ==20512== by 0x4A8A64: hist_entry_iter__add (hist.c:876) > ==20512== by 0x43787A: perf_event__process_sample (builtin-top.c:787) > ==20512== by 0x43787A: perf_top__mmap_read_idx (builtin-top.c:854) > ==20512== by 0x43967E: perf_top__mmap_read (builtin-top.c:871) > ==20512== by 0x43967E: __cmd_top (builtin-top.c:996) > ==20512== by 0x43967E: cmd_top (builtin-top.c:1266) > ==20512== by 0x41B702: run_builtin (perf.c:341) > ==20512== by 0x41AE51: handle_internal_command (perf.c:400) > ==20512== by 0x41AE51: run_argv (perf.c:444) > ==20512== by 0x41AE51: main (perf.c:559) Same thing as #1. > ==20512== > ==20512== 26,147,680 bytes in 62,855 blocks are possibly lost in loss record 299 of 301 > ==20512== at 0x402B000: calloc (vg_replace_malloc.c:623) > ==20512== by 0x4A6996: zalloc (util.h:189) > ==20512== by 0x4A6996: hist_entry__new (hist.c:309) > ==20512== by 0x4A8249: add_hist_entry (hist.c:431) > ==20512== by 0x4A8249: __hists__add_entry (hist.c:477) > ==20512== by 0x4A8728: iter_add_next_cumulative_entry (hist.c:803) > ==20512== by 0x4A8AA5: hist_entry_iter__add (hist.c:887) > ==20512== by 0x43787A: perf_event__process_sample (builtin-top.c:787) > ==20512== by 0x43787A: perf_top__mmap_read_idx (builtin-top.c:854) > ==20512== by 0x43967E: perf_top__mmap_read (builtin-top.c:871) > ==20512== by 0x43967E: __cmd_top (builtin-top.c:996) > ==20512== by 0x43967E: cmd_top (builtin-top.c:1266) > ==20512== by 0x41B702: run_builtin (perf.c:341) > ==20512== by 0x41AE51: handle_internal_command (perf.c:400) > ==20512== by 0x41AE51: run_argv (perf.c:444) > ==20512== by 0x41AE51: main (perf.c:559) > ==20512== > ==20512== 44,939,792 bytes in 3,788 blocks are definitely lost in loss record 300 of 301 > ==20512== at 0x402B000: calloc (vg_replace_malloc.c:623) > ==20512== by 0x44F7BF: zalloc (util.h:189) > ==20512== by 0x44F7BF: symbol__alloc_hist (annotate.c:455) > ==20512== by 0x44F7BF: symbol__inc_addr_samples (annotate.c:507) > ==20512== by 0x44F7BF: hist_entry__inc_addr_samples (annotate.c:521) > ==20512== by 0x437A65: perf_top__record_precise_ip (builtin-top.c:195) > ==20512== by 0x437A65: hist_iter__top_callback (builtin-top.c:688) > ==20512== by 0x4A8AC8: hist_entry_iter__add (hist.c:892) > ==20512== by 0x43787A: perf_event__process_sample (builtin-top.c:787) > ==20512== by 0x43787A: perf_top__mmap_read_idx (builtin-top.c:854) > ==20512== by 0x4395EE: perf_top__mmap_read (builtin-top.c:871) > ==20512== by 0x4395EE: __cmd_top (builtin-top.c:974) > ==20512== by 0x4395EE: cmd_top (builtin-top.c:1266) > ==20512== by 0x41B702: run_builtin (perf.c:341) > ==20512== by 0x41AE51: handle_internal_command (perf.c:400) > ==20512== by 0x41AE51: run_argv (perf.c:444) > ==20512== by 0x41AE51: main (perf.c:559) > ==20512== > ==20512== 81,248,440 bytes in 1,450,865 blocks are possibly lost in loss record 301 of 301 > ==20512== at 0x402B000: calloc (vg_replace_malloc.c:623) > ==20512== by 0x4821FE: zalloc (util.h:189) > ==20512== by 0x4821FE: fill_node (callchain.c:450) > ==20512== by 0x4821FE: add_child (callchain.c:473) > ==20512== by 0x4821FE: append_chain_children (callchain.c:596) > ==20512== by 0x48514E: callchain_append (callchain.c:672) > ==20512== by 0x4A8768: iter_add_next_cumulative_entry (hist.c:812) > ==20512== by 0x4A8AA5: hist_entry_iter__add (hist.c:887) > ==20512== by 0x43787A: perf_event__process_sample (builtin-top.c:787) > ==20512== by 0x43787A: perf_top__mmap_read_idx (builtin-top.c:854) > ==20512== by 0x43967E: perf_top__mmap_read (builtin-top.c:871) > ==20512== by 0x43967E: __cmd_top (builtin-top.c:996) > ==20512== by 0x43967E: cmd_top (builtin-top.c:1266) > ==20512== by 0x41B702: run_builtin (perf.c:341) > ==20512== by 0x41AE51: handle_internal_command (perf.c:400) > ==20512== by 0x41AE51: run_argv (perf.c:444) > ==20512== by 0x41AE51: main (perf.c:559) > ==20512== > ==20512== LEAK SUMMARY: > ==20512== definitely lost: 56,810,427 bytes in 5,479 blocks > ==20512== indirectly lost: 4,000 bytes in 125 blocks > ==20512== possibly lost: 210,493,048 bytes in 2,552,578 blocks > ==20512== still reachable: 18,258 bytes in 242 blocks > ==20512== suppressed: 0 bytes in 0 blocks > > -- > Markus ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: "perf top -g" leaking ~300MB per second. 2014-12-30 5:38 ` Namhyung Kim 2014-12-30 8:35 ` Markus Trippelsdorf @ 2015-01-08 15:09 ` Arnaldo Carvalho de Melo 2015-01-09 12:31 ` [tip:perf/urgent] perf callchain: Free callchains when hist entries are deleted tip-bot for Namhyung Kim 2 siblings, 0 replies; 9+ messages in thread From: Arnaldo Carvalho de Melo @ 2015-01-08 15:09 UTC (permalink / raw) To: Namhyung Kim Cc: David Ahern, Markus Trippelsdorf, linux-kernel, Peter Zijlstra, Paul Mackerras, Ingo Molnar Em Tue, Dec 30, 2014 at 02:38:13PM +0900, Namhyung Kim escreveu: > Subject: [PATCH] perf callchain: Free callchains when hist entries are deleted > Markus reported that "perf top -g" can leak ~300MB per second on his > machine. This is partly because it missed to free callchains when > hist entries are deleted. Fix it. Thanks, applied. - Arnaldo ^ permalink raw reply [flat|nested] 9+ messages in thread
* [tip:perf/urgent] perf callchain: Free callchains when hist entries are deleted 2014-12-30 5:38 ` Namhyung Kim 2014-12-30 8:35 ` Markus Trippelsdorf 2015-01-08 15:09 ` Arnaldo Carvalho de Melo @ 2015-01-09 12:31 ` tip-bot for Namhyung Kim 2 siblings, 0 replies; 9+ messages in thread From: tip-bot for Namhyung Kim @ 2015-01-09 12:31 UTC (permalink / raw) To: linux-tip-commits Cc: hpa, mingo, linux-kernel, namhyung, acme, fweisbec, dsahern, a.p.zijlstra, markus, tglx, paulus, mingo Commit-ID: d114960c488b5a95705a04bba305f931cef0efd6 Gitweb: http://git.kernel.org/tip/d114960c488b5a95705a04bba305f931cef0efd6 Author: Namhyung Kim <namhyung@kernel.org> AuthorDate: Tue, 30 Dec 2014 14:38:13 +0900 Committer: Arnaldo Carvalho de Melo <acme@redhat.com> CommitDate: Thu, 8 Jan 2015 11:56:35 -0300 perf callchain: Free callchains when hist entries are deleted Markus reported that "perf top -g" can leak ~300MB per second on his machine. This is partly because it missed to free callchains when hist entries are deleted. Fix it. Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Markus Trippelsdorf <markus@trippelsdorf.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/20141230053813.GD6081@sejong Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> --- tools/perf/util/callchain.c | 30 ++++++++++++++++++++++++++++++ tools/perf/util/callchain.h | 2 ++ tools/perf/util/hist.c | 1 + 3 files changed, 33 insertions(+) diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c index 64b377e..14e7a12 100644 --- a/tools/perf/util/callchain.c +++ b/tools/perf/util/callchain.c @@ -841,3 +841,33 @@ char *callchain_list__sym_name(struct callchain_list *cl, return bf; } + +static void free_callchain_node(struct callchain_node *node) +{ + struct callchain_list *list, *tmp; + struct callchain_node *child; + struct rb_node *n; + + list_for_each_entry_safe(list, tmp, &node->val, list) { + list_del(&list->list); + free(list); + } + + n = rb_first(&node->rb_root_in); + while (n) { + child = container_of(n, struct callchain_node, rb_node_in); + n = rb_next(n); + rb_erase(&child->rb_node_in, &node->rb_root_in); + + free_callchain_node(child); + free(child); + } +} + +void free_callchain(struct callchain_root *root) +{ + if (!symbol_conf.use_callchain) + return; + + free_callchain_node(&root->node); +} diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h index dbc08cf..c0ec1ac 100644 --- a/tools/perf/util/callchain.h +++ b/tools/perf/util/callchain.h @@ -198,4 +198,6 @@ static inline int arch_skip_callchain_idx(struct thread *thread __maybe_unused, char *callchain_list__sym_name(struct callchain_list *cl, char *bf, size_t bfsize, bool show_dso); +void free_callchain(struct callchain_root *root); + #endif /* __PERF_CALLCHAIN_H */ diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c index 0ced178..1823955 100644 --- a/tools/perf/util/hist.c +++ b/tools/perf/util/hist.c @@ -947,6 +947,7 @@ void hist_entry__free(struct hist_entry *he) zfree(&he->mem_info); zfree(&he->stat_acc); free_srcline(he->srcline); + free_callchain(he->callchain); free(he); } ^ permalink raw reply related [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-01-09 12:31 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-12-13 8:48 "perf top -g" leaking ~300MB per second Markus Trippelsdorf 2014-12-13 9:03 ` Markus Trippelsdorf 2014-12-13 15:26 ` Arnaldo Carvalho de Melo 2014-12-13 18:16 ` David Ahern 2014-12-30 5:38 ` Namhyung Kim 2014-12-30 8:35 ` Markus Trippelsdorf 2014-12-30 23:04 ` Arnaldo Carvalho de Melo 2015-01-08 15:09 ` Arnaldo Carvalho de Melo 2015-01-09 12:31 ` [tip:perf/urgent] perf callchain: Free callchains when hist entries are deleted tip-bot for Namhyung Kim
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.