"perf top -g" leaking ~300MB per second.

DISCUSSION Applied Markus Trippelsdorf 5 participants 9 messages Dec 13, 2014 – Jan 9, 2015 perf events

lore

Share & tools

lore

Markus Trippelsdorf

author

2014-12-13 08:48 UTC #0 lore raw

Running "perf top -g" built from current Linus tree apparently leaks ~300MB of memory every second an my machine.

Signature · 1 line

Markus

Markus Trippelsdorf

author

2014-12-13 09:03 UTC #1 lore raw

Quoted 2 lines · Markus Trippelsdorf

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.

Signature · 1 line

Markus

Arnaldo Carvalho de Melo

maintainer

2014-12-13 15:26 UTC #2 lore raw

Em Sat, Dec 13, 2014 at 10:03:31AM +0100, Markus Trippelsdorf escreveu:

Quoted 9 lines · Markus Trippelsdorf

Quoted 2 lines
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

David Ahern

2014-12-13 18:16 UTC #3 lore raw

Quoted 5 lines · Arnaldo Carvalho de Melo

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

Namhyung Kim

maintainer

2014-12-30 05:37 UTC #4 lore raw

Hi David and Markus,

Quoted 8 lines · David Ahern

Quoted 5 lines · Arnaldo Carvalho de Melo
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?

Quoted 1 line

From b29ccd79727654653986ab1170e0b1f5d6518035 Mon Sep 17 00:00:00 2001

From: Namhyung Kim <[email protected]>
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 <[email protected]>

Cc Frederic Weisbecker <[email protected]>

Signed-off-by Namhyung Kim <[email protected]>

---
 tools/perf/util/callchain.c | 30 ++++++++++++++++++++++++++++++
 tools/perf/util/callchain.h |  2 ++
 tools/perf/util/hist.c      |  1 +
 3 files changed, 33 insertions(+)

tools/perf/util/callchain.c +30 -0

index 64b377e591e4..14e7a123d43b 100644
@@ -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);
+}

tools/perf/util/callchain.h +2 -0

index dbc08cf5f970..c0ec1acc38e4 100644
@@ -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 */

tools/perf/util/hist.c +1 -0

index 30ff2cb92884..e17163fcb702 100644
@@ -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);
 }

Signature · 1 line

2.1.3

Markus Trippelsdorf

author

2014-12-30 08:35 UTC #5 lore raw

Quoted 10 lines · Namhyung Kim

Hi David and Markus,
Quoted 7 lines · David Ahern
Quoted 5 lines · Arnaldo Carvalho de Melo
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...

Quoted 5 lines

Quoted 1 line
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

Signature · 1 line

Markus

Arnaldo Carvalho de Melo

maintainer

2014-12-30 23:04 UTC #6 lore raw

Em Tue, Dec 30, 2014 at 09:35:24AM +0100, Markus Trippelsdorf escreveu:

Quoted 23 lines · Namhyung Kim

Quoted 10 lines
Hi David and Markus,
Quoted 7 lines · David Ahern
Quoted 5 lines · Arnaldo Carvalho de Melo
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...
Quoted 5 lines
Quoted 1 line
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

Quoted 16 lines

==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.

Quoted 31 lines

==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)

Quoted 8 lines

==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...

Quoted 18 lines

==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.

Quoted 66 lines

==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)

Signature · 1 line

Markus

Arnaldo Carvalho de Melo

maintainer Applied

2015-01-08 15:09 UTC #7 lore raw

In reply to Namhyung Kim

Em Tue, Dec 30, 2014 at 02:38:13PM +0900, Namhyung Kim escreveu:

Quoted 5 lines

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

tip-bot for Namhyung Kim

merge bot

2015-01-09 12:31 UTC #8 lore raw

[tip:perf/urgent] perf callchain: Free callchains when hist entries are deleted

In reply to Namhyung Kim

perf callchain: Free callchains when hist entries are deleted

Commit-ID:  d114960c488b5a95705a04bba305f931cef0efd6
Gitweb:     http://git.kernel.org/tip/d114960c488b5a95705a04bba305f931cef0efd6
Author:     Namhyung Kim <[email protected]>
AuthorDate: Tue, 30 Dec 2014 14:38:13 +0900
Committer:  Arnaldo Carvalho de Melo <[email protected]>
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 <[email protected]>

Signed-off-by Namhyung Kim <[email protected]>

Cc David Ahern <[email protected]>

Cc Frederic Weisbecker <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Markus Trippelsdorf <[email protected]>

Cc Paul Mackerras <[email protected]>

Cc Peter Zijlstra <[email protected]>

Link http://lkml.kernel.org/r/20141230053813.GD6081@sejong open here

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

---
 tools/perf/util/callchain.c | 30 ++++++++++++++++++++++++++++++
 tools/perf/util/callchain.h |  2 ++
 tools/perf/util/hist.c      |  1 +
 3 files changed, 33 insertions(+)

tools/perf/util/callchain.c +30 -0

index 64b377e..14e7a12 100644
@@ -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);
+}

tools/perf/util/callchain.h +2 -0

index dbc08cf..c0ec1ac 100644
@@ -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 */

tools/perf/util/hist.c +1 -0

index 0ced178..1823955 100644
@@ -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);
 }