Re: [PATCH 0/2] perf: add sort by inclusive time functionality (v2)
Hi, 2012-03-09 3:49 AM, Arun Sharma wrote: On 3/8/12 7:31 AM, Frederic Weisbecker wrote: On Thu, Mar 08, 2012 at 08:29:01AM +0100, Ingo Molnar wrote: * Arun Sharma wrote: This patch series refactors existing code a bit and adds sort by inclusive time (time spent in the function + callees). Sample command lines: # perf record -ag -- sleep 1 # perf report -g graph,0.5,callee -n -s inclusive So I tried this out with: $ taskset 1 perf record -g git gc and got entries above 100% (in the TUI): $ perf report -g graph,0.5,callee -n -s inclusive + 321.11% 5628 [.] 0x392b609269 + 142.27% 3774 [.] create_delta + 78.86% 1248 [.] lookup_object + 40.54% 1348 [k] system_call_fastpath [...] Is that expected? Yes - this is the "known bug" I noted in the cover letter The second column (samples) is still accurate and could be used for the analysis. I think this happens because of this: - hists->stats.total_period += h->period; + if (!h->inclusive) + hists->stats.total_period += h->period; Which I'm not sure why it is needed btw. Suppose the perf.data file had 1000 samples each with a period of 1e6 events. total_period would be 1e9 without -s inclusive. Further, let's say the callchains had an average length of 10. Now, after adding extra entries to the histogram, total_period would be 1e10, which screws up the percentages. I'd like to differentiate between the hist entries that were in the event stream vs the ones added for inclusive time computation. Desired end result: the total_period remains unchanged at 1e9. This is done via: + if (i != 0) + he->inclusive = 1; + else + orig_he = he; Either (i != 0) is not a good enough test, or the inclusive bit is not getting propagated properly after histogram collapsing/resorting. This is the part I need to better understand and debug. I tried to explain this problem in my first RFC message as well: http://thread.gmane.org/gmane.linux.kernel/1262289 The problem Ingo is running into (and I've reproduced it on my end as well) is that total_period is smaller than without -s inclusive i.e. h->inclusive is 1 when it shouldn't be. I think it's because of the shared hist_entry. If a callchain is a subset of another, it will be marked as inclusive so that it cannot be contributed to total period. Say, there're two chains - X (a -> b -> c) and Y (a -> b), once __hists__add_entry_inclusive() was called on X, we have: a -> b -> c a -> b (inclusive) a (inclusive) And then, calling the function on Y should make: a -> b a (inclusive) However, since both callchains are in tree already they'll be shared and marked *inclusive*. Thus the total period will not increased at all for Y. Also I guess the reverse case - add Y first, and then X - will have the same result. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] perf: add sort by inclusive time functionality (v2)
Hi, 2012-03-08 7:41 AM, Arun Sharma wrote: This patch series refactors existing code a bit and adds sort by inclusive time (time spent in the function + callees). Sample command lines: # perf record -ag -- sleep 1 # perf report -g graph,0.5,callee -n -s inclusive Known bugs: total_period computation is broken for order=callee I'd like to add two more :). * If perf record misses callchain info, perf report will get stuck. * If it's used with "symbol" sort order, it'll get stuck too. BTW, I don't like the name 'inclusive' as a sort key. If it cares about time, IMHO, the name should contain 'time' - something like 'itime' or 'inctime'? Furthermore, I don't think it is a sort key. As it doesn't sort anything, and only affects the way calculating symbol's period value, wouldn't it be better making it a separate switch rather than a sort key? Plus, checking whether it has callchain data and symbol sort key might be added also. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] perf: add sort by inclusive time functionality (v2)
2012-03-13 3:05 AM, Arun Sharma wrote:
On 3/12/12 12:15 AM, Namhyung Kim wrote:
I think it's because of the shared hist_entry. If a callchain is a
subset of another, it will be marked as inclusive so that it cannot be
contributed to total period. Say, there're two chains - X (a -> b -> c)
and Y (a -> b), once __hists__add_entry_inclusive() was called on X, we
have:
a -> b -> c
a -> b (inclusive)
a (inclusive)
And then, calling the function on Y should make:
a -> b
a (inclusive)
However, since both callchains are in tree already they'll be shared and
marked *inclusive*. Thus the total period will not increased at all for
Y. Also I guess the reverse case - add Y first, and then X - will have
the same result.
Thanks for figuring this out. Looks like using a single bit (he->inclusive) is
insufficient. How about:
struct hist_entry {
u64 period;
u64 period_self;
..
};
Normal mode: period_self == period.
Inclusive mode: period_self will be zero for inclusive hist_entries.
Shared entries: we sum up both period and period_self.
We can then compute total_period by summing up period_self.
Yeah, I agree that we need that kind of code to handle total_period properly.
Looking forward to your v3 :).
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] perf: add sort by inclusive time functionality (v2)
2012-03-13 3:21 AM, Arun Sharma wrote: On 3/12/12 12:43 AM, Namhyung Kim wrote: Known bugs: total_period computation is broken for order=callee I'd like to add two more :). * If perf record misses callchain info, perf report will get stuck. * If it's used with "symbol" sort order, it'll get stuck too. Can you post the command lines you used to reproduce this? A backtrace on where perf report is getting stuck would be useful as well. $ perf record sleep 1 $ perf report -s inclusive and $ perf record -g sleep 1 $ perf report -s inclusive,symbol Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] perf: add sort by inclusive time functionality (v2)
Hi, 2012-03-13 4:58 AM, Arun Sharma wrote: On 3/12/12 11:21 AM, Arun Sharma wrote: BTW, I don't like the name 'inclusive' as a sort key. If it cares about time, IMHO, the name should contain 'time' - something like 'itime' or 'inctime'? The existing sort orders: pid, comm, dso, symbol, parent -- all care about time, but none of them have time in their name? I'll take that back. What they sort on depends on the event. perf record -ge cache-misses perf report -s inclusive will sort by the number of cache-misses and not time. -Arun AFAIK, "sort" here means how perf identifies a sample event from others: "comm" will collect samples have same pid/comm, then "dso" will group samples belong to same library, and "symbol" will group again samples have same symbol name. This is what default sort order (comm,dso,symbol) does. In case of "inclusive" it does same thing with "symbol" as you use sort_sym for the inclusive sort_dimension. Sorting by period for output is done at final stage and it won't be affected by any sort orders. It maybe sound confusing but that's how it works. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] perf: Add a new sort order: SORT_INCLUSIVE (v3)
Hi Arun,
2012-03-14 3:46 AM, Arun Sharma wrote:
Each entry that used to get added once to the histogram, now is added
chain->nr times, each time with one less entry in the
callchain.
This will result in a non-leaf function that appears in a lot of
samples to get a histogram entry with lots of hits.
The user can then drill down into the callchains of functions that
have high inclusive times.
Sample command lines:
$ perf record -ag -- sleep 1
$ perf report -g graph,0.5,callee -n -s inclusive
Signed-off-by: Arun Sharma
Cc: Ingo Molnar
CC: Arnaldo Carvalho de Melo
Cc: Frederic Weisbecker
Cc: Mike Galbraith
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Namhyung Kim
Cc: Tom Zanussi
Cc: linux-ker...@vger.kernel.org
Cc: linux-perf-users@vger.kernel.org
---
tools/perf/builtin-annotate.c |2 +-
tools/perf/builtin-diff.c |2 +-
tools/perf/builtin-report.c | 13 ++
tools/perf/builtin-top.c |2 +-
tools/perf/util/callchain.c | 14 +++
tools/perf/util/callchain.h |4 ++
tools/perf/util/hist.c| 83 -
tools/perf/util/hist.h|4 +-
tools/perf/util/sort.c| 10 +
tools/perf/util/sort.h|3 +
10 files changed, 123 insertions(+), 14 deletions(-)
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 806e0a2..5651b7b 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -62,7 +62,7 @@ static int perf_evsel__add_sample(struct perf_evsel *evsel,
return 0;
}
- he = __hists__add_entry(&evsel->hists, al, NULL, 1);
+ he = __hists__add_entry(&evsel->hists, al, NULL, NULL, 1);
if (he == NULL)
return -ENOMEM;
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 4f19513..4a30856 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -27,7 +27,7 @@ static bool show_displacement;
static int hists__add_entry(struct hists *self,
struct addr_location *al, u64 period)
{
- if (__hists__add_entry(self, al, NULL, period) != NULL)
+ if (__hists__add_entry(self, al, NULL, NULL, period) != NULL)
return 0;
return -ENOMEM;
}
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 25d34d4..f20587f 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -61,6 +61,7 @@ static int perf_evsel__add_hist_entry(struct perf_evsel
*evsel,
struct symbol *parent = NULL;
int err = 0;
struct hist_entry *he;
+ struct callchain_cursor *cursor;
if ((sort__has_parent || symbol_conf.use_callchain)&&
sample->callchain) {
err = machine__resolve_callchain(machine, evsel, al->thread,
@@ -69,17 +70,12 @@ static int perf_evsel__add_hist_entry(struct perf_evsel
*evsel,
return err;
}
- he = __hists__add_entry(&evsel->hists, al, parent, sample->period);
+ cursor =&evsel->hists.callchain_cursor;
+ he = __hists__add_entry(&evsel->hists, al, parent,
+ cursor, sample->period);
if (he == NULL)
return -ENOMEM;
- if (symbol_conf.use_callchain) {
- err = callchain_append(he->callchain,
- &evsel->hists.callchain_cursor,
- sample->period);
- if (err)
- return err;
- }
/*
* Only in the newt browser we are doing integrated annotation,
* so we don't allocated the extra space needed because the stdio
@@ -595,6 +591,7 @@ int cmd_report(int argc, const char **argv, const char
*prefix __used)
sort_entry__setup_elide(&sort_dso, symbol_conf.dso_list, "dso", stdout);
sort_entry__setup_elide(&sort_comm, symbol_conf.comm_list, "comm",
stdout);
sort_entry__setup_elide(&sort_sym, symbol_conf.sym_list, "symbol",
stdout);
+ sort_entry__setup_elide(&sort_sym_inclusive, symbol_conf.sym_list,
"inclusive", stdout);
return __cmd_report(&report);
}
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index e3c63ae..41e7153 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -235,7 +235,7 @@ static struct hist_entry *perf_evsel__add_hist_entry(struct
perf_evsel *evsel,
{
struct hist_entry *he;
- he = __hists__add_entry(&evsel->hists, al, NULL, sample->period);
+ he = __hists__add_entry(&evsel->hists, al, NULL, NULL, sample->period);
if (he == NULL)
return NULL;
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index 9f7106a..aa4acde 100644
--- a/tools/perf/util/ca
Re: [PATCH] perf: Add a new sort order: SORT_INCLUSIVE (v4)
2012-03-15 2:36 AM, Arun Sharma wrote: Each entry that used to get added once to the histogram, now is added chain->nr times, each time with one less entry in the callchain. This will result in a non-leaf function that appears in a lot of samples to get a histogram entry with lots of hits. The user can then drill down into the callchains of functions that have high inclusive times. Sample command lines: $ perf record -ag -- sleep 1 $ perf report -g graph,0.5,callee -n -s inclusive Reviewed-by: Namhyung Kim Thanks, looks good to me now - although I still prefer make it a switch to alter the behavior of the existing "symbol" sort order to do "inclusive" calculation of its periods, but I can live with this :). Signed-off-by: Arun Sharma Cc: Ingo Molnar CC: Arnaldo Carvalho de Melo Cc: Frederic Weisbecker Cc: Mike Galbraith Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Namhyung Kim Cc: Tom Zanussi Cc: linux-ker...@vger.kernel.org Cc: linux-perf-users@vger.kernel.org --- tools/perf/builtin-annotate.c |2 +- tools/perf/builtin-diff.c |2 +- tools/perf/builtin-report.c | 13 +++ tools/perf/builtin-top.c |2 +- tools/perf/util/callchain.c | 15 tools/perf/util/callchain.h |4 ++ tools/perf/util/hist.c| 80 +++- tools/perf/util/hist.h|4 ++- tools/perf/util/sort.c| 14 +++ tools/perf/util/sort.h|4 ++ 10 files changed, 126 insertions(+), 14 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LLC-* events not working on sandybridge
Hi,
On Sun, 29 Apr 2012 00:03:14 +0100, David Wragg wrote:
> Hi,
>
> I've run into a problem with perf on an Intel Sandybridge machine: The
> LLC-* events never seem to trigger.
>
> For example:
>
> $ perf stat -e LLC-load-misses ls /
> [...]
> 0 LLC-load-misses
>
>0.001082639 seconds time elapsed
>
> Non-LLC events work fine:
>
> $ perf stat -e cache-misses ls /
> [...]
> 4,272 cache-misses
>
>0.002945606 seconds time elapsed
>
> This is on a Intel i5 machine (i5-2520M), running a fully updated Fedora
> 16 ('perf --version': 3.3.2-6.fc16.x86_64, 'uname -r':
> 3.3.2-6.fc16.x86_64).
>
> Any ideas?
>
> David
I have a same problem on my i7-3930K machine. I guess it's because of
lacking of extra register (MSP_OFFCORE_RSP_X) settings. But I have no
idea of how I can set it properly :(.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LLC-* events not working on sandybridge
Hi, On Mon, 30 Apr 2012 18:50:39 +0100, David Wragg wrote: > Namhyung Kim writes: >> On Sun, 29 Apr 2012 00:03:14 +0100, David Wragg wrote: >>> I've run into a problem with perf on an Intel Sandybridge machine: The >>> LLC-* events never seem to trigger. >>> [...] >> >> I have a same problem on my i7-3930K machine. I guess it's because of >> lacking of extra register (MSP_OFFCORE_RSP_X) settings. But I have no >> idea of how I can set it properly :(. > > Ok, I've done some further digging around, and it doesn't look like the > patch "perf events, x86: Implement Sandybridge last-level cache events" > at <https://lkml.org/lkml/2011/5/9/80> ever got merged. It's not clear > why. > It seems that PeterZ and Ingo don't want an unverified patch get merged. But you can still test with it and, hopefully, provide us a verification :). Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] perf top -G is broken
Hi,
Some guy reported me that perf top -G is broken with segment fault. I
can reproduce it on my system easily but the time is vary - few seconds
to 30 minutes. I ran it with --stdio to get a core file:
$ sudo ./perf top -G --stdio > /dev/null
[sudo] password for namhyung:
Failed to open /tmp/perf-1313.map, continuing without symbols
Warning: empty node in callchain tree
Warning: empty node in callchain tree
/usr/lib64/libgvfscommon.so.0.0.0.#prelink#.SjIuuf was updated (is prelink
enabled?). Restart the long running apps that use it!
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
no symbols found in /usr/sbin/iscsid, maybe install a debug package?
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
Warning: empty node in callchain tree
It seems there's a callchain problem. gdb bracktrace told me:
$ gdb -q ./perf core.4513
Reading symbols from /home/namhyung/project/linux/tools/perf/perf...done.
[New LWP 4514]
[New LWP 4513]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `./perf top -G --stdio'.
Program terminated with signal 11, Segmentation fault.
#0 0x004594ba in callchain_cursor_advance (cursor=) at
util/callchain.h:141
141 cursor->curr = cursor->curr->next;
Missing separate debuginfos, use:
(gdb) bt
#0 0x004594ba in callchain_cursor_advance (cursor=) at
util/callchain.h:141
#1 fill_node (cursor=0x19ad6f8, node=0x7f8208697df0) at util/callchain.c:226
#2 add_child (period=1198958, cursor=0x19ad6f8, parent=0x21197c0) at
util/callchain.c:239
#3 append_chain_children (root=root@entry=0x21197c0,
cursor=cursor@entry=0x19ad6f8, period=period@entry=1198958)
at util/callchain.c:308
#4 0x0045951f in append_chain (period=1198958, cursor=0x19ad6f8,
root=0x21197c0) at util/callchain.c:374
#5 append_chain_children (root=root@entry=0x1a25f90,
cursor=cursor@entry=0x19ad6f8, period=1198958) at util/callchain.c:302
#6 0x00459a33 in merge_chain_branch (cursor=cursor@entry=0x19ad6f8,
dst=dst@entry=0x1a25f90, src=src@entry=0x28c3240)
at util/callchain.c:415
#7 0x0045999a in merge_chain_branch (cursor=cursor@entry=0x19ad6f8,
dst=dst@entry=0x1a25f90, src=src@entry=0x29e7480)
at util/callchain.c:419
#8 0x0045a274 in callchain_merge (cursor=cursor@entry=0x19ad6f8,
dst=dst@entry=0x1a25f88, src=src@entry=0x29e7478)
at util/callchain.c:436
#9 0x004776fe in hists__collapse_insert_entry (he=0x29e73d0,
root=0x19ad540, hists=0x19ad520) at util/hist.c:401
#10 __hists__collapse_resort (hists=0x19ad520, threaded=threaded@entry=true) at
util/hist.c:458
#11 0x004791f1 in hists__collapse_resort_threaded (hists=) at util/hist.c:476
#12 0x00426ad3 in perf_top__print_sym_table (top=0x7fffb70097c0) at
builtin-top.c:309
#13 display_thread (arg=0x7fffb70097c0) at builtin-top.c:623
#14 0x003275607d14 in start_thread () from /lib64/libpthread.so.0
#15 0x0032752f194d in clone () from /lib64/libc.so.6
(gdb) p *(struct callchain_cursor *)0x19ad6f8
$1 = {nr = 1, first = 0x1a097a0, last = 0x1a097b8, pos = 1, curr = 0x19c6a90}
I wonder how callchain_cursor_advance() is called in fill_node() when
cursor->pos == cursor->nr. It should be checked at while conditional and
bailed out AFAICS.
Any thought?
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] perf top -G is broken
Hi, On Wed, 2 May 2012 13:02:50 -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, May 02, 2012 at 11:50:45AM +0900, Namhyung Kim escreveu: >> Some guy reported me that perf top -G is broken with segment fault. I >> can reproduce it on my system easily but the time is vary - few seconds >> to 30 minutes. I ran it with --stdio to get a core file: > > Does it help to increase --mmap-pages from its default, 128, to > something like 512 or more? > > Also try running with -r 90. > > - Arnaldo Testing both options with current tip/perf/core gives me the same result. :( Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: using perf lock
Hi, On Wed, 23 May 2012 15:42:42 + (UTC), Hank wrote: > I've been trying to use perf lock command on my Ubuntu 12.04, but I'm getting > this error: > > invalid or unsupported event: 'lock:lock_acquire' > > What might be the problem? Should I get the kernel source code? > Maybe due to the kernel was built without CONFIG_LOCKDEP and/or CONFIG_LOCK_STAT. You can grep it from /boot/config-$(uname -r). If so, you need to rebuild the kernel. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Perf 2.6.32-220.el6.x86_64 problem when recording 2 counters
Hi, On Wed, 23 May 2012 18:06:59 +0200, HUMMEL Michel wrote: > Hello, > I am testing the perf command of my new centos 6.2 server, and I don't > understand something. > My Conf : > > $ grep name /proc/cpuinfo > model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz > $ uname -a > Linux 2.6.32-220.el6.x86_64 #1 SMP Tue Dec 6 19:48:22 GMT 2011 > x86_64 x86_64 x86_64 GNU/Linux > $ perf --version > perf version 2.6.32-220.el6.x86_64.debug > $ perf test > 1: vmlinux symtab matches kallsyms: FAILED! > > 2: detect open syscall event: Ok > 3: detect open syscall event on all cpus: Ok > 4: read samples using the mmap interface: Ok > > > I wrote a simple test case which is calling two functions. > The first one "good_perfo" does the same as the second "bad_perfo" but more > efficiently (lesser cache miss ...). > > Gprof profile confirms this : > > $ gprof -p ./test_perfo > Flat profile: > > Each sample counts as 0.01 seconds. > % cumulative self self total > time seconds secondscalls s/call s/call name > 76.14 38.7538.75138.7538.75 bad_perfo > 23.70 50.8112.06112.0612.06 good_perfo > > > but perf don't want to give me the good answer when I asking for two events : > cycles and instructions : > > $ perf record -e cycles,instructions -o perf.data.cycles.instructions > ./test_perfo > $ perf report -i perf.data.cycles.instructions --stdio > # Events: 5K cycles > # One thing I noticed is the number of events in this run is much smaller than others (5K to 51K). Probably it can be a reason of the inaccuracy, but I'm not sure. Maybe increasing sampling freq (-F) or adding the 'u' modifier on events can help. Thanks, Namhyung > # Overhead Command Shared Object Symbol > # ... . .. > # > 99.35% test_perfo test_perfo [.] good_perfo > 0.14% test_perfo [kernel.kallsyms] [k] clear_page_c > 0.08% test_perfo [kernel.kallsyms] [k] page_fault > 0.05% test_perfo [kernel.kallsyms] [k] hrtimer_interrupt > > > # Events: 5K instructions > # > # Overhead Command Shared Object Symbol > # ... . . > # > 99.93% test_perfo test_perfo [.] good_perfo > 0.02% test_perfo [kernel.kallsyms] [k] __run_hrtimer > 0.02% test_perfo [kernel.kallsyms] [k] inode_has_perm > 0.02% test_perfo [kernel.kallsyms] [k] update_wall_time > > > > The bad_perfo function is not appearing in the profile (and I am sure that it > should !) > Now if I do 2 separate records, one for the cycles and one for the > instructions, the profile seems to be good : > > > $ perf record -e cycles -o perf.data.cycles ./test_perfo > $ perf report -i perf.data.cycles --stdio > # Events: 51K cycles > # > # Overhead Command Shared Object Symbol > # ... . .. > # > 76.20% test_perfo test_perfo [.] bad_perfo > 23.36% test_perfo test_perfo [.] good_perfo > 0.03% test_perfo [kernel.kallsyms] [k] apic_timer_interrupt > 0.02% test_perfo [kernel.kallsyms] [k] do_softirq > 0.02% test_perfo [kernel.kallsyms] [k] avc_has_perm_noaudit > > $ perf record -e instructions -o perf.data.instructions ./test_perfo > $ perf report -i perf.data.instructions --stdio > # Events: 45K instructions > # > # Overhead Command Shared ObjectSymbol > # ... . > # > 49.95% test_perfo test_perfo [.] bad_perfo > 49.94% test_perfo test_perfo [.] good_perfo > 0.01% test_perfo [kernel.kallsyms] [k] raise_softirq > 0.01% test_perfo [kernel.kallsyms] [k] hrtimer_interrupt > 0.01% test_perfo [kernel.kallsyms] [k] kmem_cache_alloc_notrace > > > Is I missed something with the perf command or this is a bug ? > > > I found a Quick&Dirty solution : > Using the -D ( Collect data without buffering ) option give me the good > profile : > > $ perf record -D -e cycles,instructions -o perf.data.cycles.instructions > ./test_perfo > $ perf report -i perf.data.cycles.instructions --stdio > # Events: 51K cycles > # > # Overhead Command
Re: Minor fix
Hi, Alexis On Mon, 25 Jun 2012 00:33:43 +0200, Alexis Berlemont wrote: > Hi, > > Has anyway try to compile perf at the latest tag (v3.5-rc4) or on > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git ? > > I did not manage to do it without this little fix. > > Did I miss something obvious? > Did you try to cross build it? There's a patch posted already. :) http://article.gmane.org/gmane.linux.kernel/1316652 Anyway, thanks for sending your patch. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Callgraph like kcachegrind
On Wed, 4 Jul 2012 21:44:28 -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Jun 28, 2012 at 02:59:39PM +0200, Christoph Bartoschek escreveu: >> is it somehow possible to get a callgraph like gets it from kcachegrind? >> >> I tried to use -g/-G on a program that runs but the information is not as >> expected. I do not see how the 100% runtime of main() is distributed. > > This is a feature we should have, but till then I think there is a > script out there that does that, lemme try to google that, gack, I know > there is one, but 'perf tools' really isn't google friendly, anyone? > I saw Arun posted a kind of cumulative (or inclusive) call graph patch long ago. I guess it'd be the first step to have the feature like above. And IIRC Ingo wanted to have it too. Arun, what's the state of the patch? Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Callgraph like kcachegrind
Hi, On Fri, Jul 6, 2012 at 9:50 AM, Arun Sharma wrote: > On 7/5/12 5:27 PM, Namhyung Kim wrote: >> >> On Wed, 4 Jul 2012 21:44:28 -0300, Arnaldo Carvalho de Melo wrote: >>> >>> Em Thu, Jun 28, 2012 at 02:59:39PM +0200, Christoph Bartoschek escreveu: >>>> >>>> is it somehow possible to get a callgraph like gets it from kcachegrind? >>>> >>>> I tried to use -g/-G on a program that runs but the information is not >>>> as >>>> expected. I do not see how the 100% runtime of main() is distributed. >>> >>> >>> This is a feature we should have, but till then I think there is a >>> script out there that does that, lemme try to google that, gack, I know >>> there is one, but 'perf tools' really isn't google friendly, anyone? >>> >> >> I saw Arun posted a kind of cumulative (or inclusive) call graph patch >> long ago. I guess it'd be the first step to have the feature like above. >> And IIRC Ingo wanted to have it too. >> >> Arun, what's the state of the patch? >> > > http://thread.gmane.org/gmane.linux.kernel.perf.user/882 is the most recent > patch I posted. > > The last comments I got were: > > * Use a global flag instead of a sort mode > * Try to integrate with LBR, branch filtering mode. > > Unfortunately, I'm tied up with other projects right now and am not able to > finish this up. Happy to answer questions about the patch if anyone wants to > take it over. > Ok, I'll try to look at it. > http://thread.gmane.org/gmane.linux.kernel.perf.user/857 (callgraph > filtering) is also related. > And this one once the above gets settled. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] perf: events defined contexts (was Re: perf: prctl(PR_TASK_PERF_EVENTS_DISABLE) has no effect)
Hi, On Fri, 27 Jul 2012 14:45:38 +0200, Jiri Olsa wrote: > On Fri, Jul 27, 2012 at 01:56:36PM +0200, Frederic Weisbecker wrote: >> The problem is more general than that I think. >> We need to be able to define finer grained contexts than just >> "task" and/or "CPU". >> >> And reusing events themselves would be a nice interface. >> >> For example create 3 events: >> >> A = irq entry tracepoint >> B = irq exit tracepoint >> C = cpu-cycles >> >> And say: I want to count cpu-cycles when event A fires and stop counting >> when B fires. >> >> With that you can count cpu cycles on irqs. >> >> You could use any event you want to define your contexts: lock, functions, >> etc... >> >> And even uprobes to define areas in userspace to profile. Would that solve >> the initial problem in the thread? Like hook on function library entry/exit? >> >> I talked about that to Jiri Olsa several times. May be he would be interested >> in implementing this. I posted some patchets one year ago but got >> sidetracked. >> >> This can give you an idea from where we can start: >> https://lkml.org/lkml/2011/3/14/346 >> >> Jiri, would you be interested in working on this? > > yep, I remember also talking about A/B being functions entry/exit > > I think that was also the initial push for having ftrace perf events > support, which already got in. > > I'll check ;) > Very cool. :) I'm also interested in the feature although my background knowledge is not firm enough yet. Please let me know if there's anything I can help you on this. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] perf: Add a new sort order: SORT_INCLUSIVE (v6)
Hi, Arun
On Wed, 8 Aug 2012 12:16:30 -0700, Arun Sharma wrote:
> On 3/30/12 10:43 PM, Arun Sharma wrote:
>> [ Meant to include v6 ChangeLog as well. Technical difficulties.. ]
>>
>> v6 ChangeLog:
>>
>> rebased to tip:perf/core and fixed a minor problem in computing
>> the total period in hists__remove_entry_filter(). Needed to
>> use period_self instead of period.
>
> This patch breaks perf top (symptom: percentages > 100%). Fixed by the
> following patch.
>
> Namhyung: if you're still working on forward porting this, please add
> this fix to your queue.
>
Will do, thanks.
Namhyung
> -Arun
>
> commit 75a1c409a529c9741f8a2f493868d1fc7ce7e06d
> Author: Arun Sharma
> Date: Wed Aug 8 11:47:02 2012 -0700
>
>perf: update period_self as well on collapsing
> When running perf top, we have a series of incoming samples,
>which get aggregated in various user specified ways.
> Suppose function "foo" had the following samples:
>101, 103, 99, 105, ...
> ->period for the corresponding entry looks as follows:
>101, 204, 303, 408, ...
> However, due to this bug, ->period_self contains:
>101, 103, 99, 105, ...
> and therefore breaks the invariant period == period_self
>in the default mode (no sort inclusive).
> Since total_period is computed by summing up period_self,
> period/total_period can be > 100%
> Fix the bug by updating period_self as well.
> Signed-off-by: Arun Sharma
>
> diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
> index a2a8d91..adc891e 100644
> --- a/tools/perf/util/hist.c
> +++ b/tools/perf/util/hist.c
> @@ -462,6 +462,7 @@ static bool hists__collapse_insert_entry(struct
> hists *hists,
>
> if (!cmp) {
> iter->period += he->period;
> + iter->period_self += he->period_self;
> iter->nr_events += he->nr_events;
> if (symbol_conf.use_callchain) {
>
> callchain_cursor_reset(&hists->callchain_cursor);
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Perf tool cross build issue
Hi, Koteswararao
On Tue, 14 Aug 2012 12:00:12 +0900, Koteswararao Nelakurthi wrote:
> Dear Perf developers,
>
>
> I am trying to cross compile Perf source present in 2.6.35/tools/perf
2.6.35? That's too old. Can't you try it with more recent version?
Thanks,
Namhyung
> directory for ARM.in ubuntu machine.(x86 is host machine).But i am
> facing the following compilation error as compiler looks at host
> specific header files instead of looking at header files present in
> perf/ directory..Please provide Makefile changes required to compile
> successfully perf for ARM.{{{
>
> perf>make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
>
> Makefile:629: No bfd.h/libbfd found, install
> binutils-dev[el]/zlib-static to gain symbol demangling
>
>CC
> /home/caveo/20120807_work/mvlinux/tools/perf/builtin-annotate.o
>
> In file included from builtin-annotate.c:22:
>
> util/parse-options.h:86: error: redefinition of 'struct option'
>
> In file included from builtin-annotate.c:26:
>
> util/hist.h:119: fatal error: newt.h: No such file or directory
> compilation terminated.
> make: *** [/home/caveo/20120807_work/mvlinux/tools/perf/builtin-annotate.o]
> Error 1
>
> }}}
>
> Thanks for your help in advance.
>
> Regards
> koteswararao
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to trace threads created by a process after perf has started recording, using the -p PID flag?
Hi, Mikolaj
On Tue, 4 Sep 2012 00:17:50 +0200, Mikolaj Konarski wrote:
>>> Could someone clarify the behaviour of the -p PID flag of perf-record?
>>> In our experiments (3.2.0-27 #43-Ubuntu SMP x86_64),
>>> it ignores events on threads spawned after perf-record is started.
>>> Is this the intended behaviour, and is there any work-around?
>
> Anybody? We'd love to use a proven, standard workaround
> for this issue, preferably without forcing our users to upgrade
> the kernel or wait for any future release. Do we even diagnose
> the problem correctly? The best workaround we can come up with
> right now is to use the "--filter 'pid=='" option, but it has
> a couple of downsides. Any help would be sincerely appreciated.
>
AFAIK perf events aren't inherited when -p, -t or -u option is used due
to a performance reason. But if you start the process on the command
line with perf record, it'll be inherited and counted properly.
I guess your problem might be solved by using a cgroup:
# mkdir ${cgroup_root}/mygroup
# echo > ${cgroup_root}/mygroup/tasks
# perf record -a -e cycles -G mygroup
>> Can you try perf from Linus' current tree? perf should be tracking threads
>> created after the record starts.
>
> Thanks for the tip, David. But are you sure there's
> anything new and relevant in the Linus' current tree?
> Could you perhaps point me to the commit that contains
> the relevant changes?
>
> The version of perf-record that we use already contains the separate
> -p PID and -t TID options, so the initial PID patch is already in.
> It's just that the -p PID option ignores all threads spawned
> after the process is started, AFAICT.
>
> OTOTH, chenggang qin, you say
>
>> I submitted a patch to fix this problem. and the patch is waitting for
>> reviewing.
>
> Could you give me a link to this patch? Does it improve
> the -p PID option or replace it or solve our problem
> in some other way? Thank you for your kind interest.
>
https://lkml.org/lkml/2012/8/22/340
But it only addresses a case of perf top.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: attr inherit vs inherit_stat
On Tue, 7 Aug 2012 15:47:32 -0400, Vince Weaver wrote: > Hello Hello Vince, > > I'm trying to figure out the difference between the "inherit" and > "inherit_stat" bitfields in the perf_event_attr structure. > > Both seem to have similar functionality, and the code in core.c > is hard to follow. > > Does anyone have any idea? AFAIK the "inherit" field determines whether the event is inherited to a child process/thread. The "inherit_stat" is only meaningful when the "inherit" field is also set and it'll preserve (saved) event counts between context switch of the inherited processes/threads. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: attr inherit vs inherit_stat
(Adding peterz in case he has a time to answer) On Thu, 6 Sep 2012 11:19:21 -0400, Vince Weaver wrote: > On Tue, 4 Sep 2012, Namhyung Kim wrote: >> >> AFAIK the "inherit" field determines whether the event is inherited to a >> child process/thread. The "inherit_stat" is only meaningful when the >> "inherit" field is also set and it'll preserve (saved) event counts >> between context switch of the inherited processes/threads. > > Thank you for taking the time to answer! > > I'm still trying to construct a test case that shows the difference but > I'm failing. Please note that my understanding of perf core code is not firm enough so there might be some mistakes. ;-) > > Aren't the stats *always* saved on context switch? If both of them are cloned from the same parent event context and there's no event added in the meantime. Please see perf_event_context_sched_out() calling perf_event_sync_stat. > > Does this affect what happens when you read the perf_event fd in the > inherited threads, or only from the master thread? It might. But I guess the master thread doesn't get affected from that. > > What is the expected behavior if you set inherit_thread but do not set > inherit? You meant inherit_stat, right? If so, it looks it'd be a nop since there's no inherited events. Maybe the perf tools can be changed to warn about that. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] A trivial memory leak fix while calling system_path
Hi, liang
On Fri, 7 Sep 2012 11:34:49 +0800, liang xie wrote:
> A trivial memory leak fix while calling system_path
>
> Since v1: Remove an unnecessary null pointer check per Felipe's comments
>
> Signed-off-by: Liang Xie
> ---
> tools/perf/util/exec_cmd.c |4 +++-
> tools/perf/util/help.c |1 +
> 2 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/tools/perf/util/exec_cmd.c b/tools/perf/util/exec_cmd.c
> index 7adf4ad..d041407 100644
> --- a/tools/perf/util/exec_cmd.c
> +++ b/tools/perf/util/exec_cmd.c
> @@ -83,8 +83,9 @@ void setup_path(void)
> {
> const char *old_path = getenv("PATH");
> struct strbuf new_path = STRBUF_INIT;
> + const char *exec_path = perf_exec_path();
>
> - add_path(&new_path, perf_exec_path());
> + add_path(&new_path, exec_path);
> add_path(&new_path, argv0_path);
>
> if (old_path)
> @@ -95,6 +96,7 @@ void setup_path(void)
> setenv("PATH", new_path.buf, 1);
>
> strbuf_release(&new_path);
> + free((void *)exec_path);
> }
The problem is that perf_exec_path() can return a non-dynamically
allocated string (e.g. command line argument or environment string) and
currently we cannot know where the returned string is came from.
It might cause much more troubles when you free that kind of string than
just leaking a couple of bytes IMHO.
Thanks,
Namhyung
>
> static const char **prepare_perf_cmd(const char **argv)
> diff --git a/tools/perf/util/help.c b/tools/perf/util/help.c
> index 6f2975a..798f66d 100644
> --- a/tools/perf/util/help.c
> +++ b/tools/perf/util/help.c
> @@ -187,6 +187,7 @@ void load_command_list(const char *prefix,
> uniq(other_cmds);
> }
> exclude_cmds(other_cmds, main_cmds);
> + free((void *)exec_path);
> }
>
> void list_commands(const char *title, struct cmdnames *main_cmds,
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] memory leak fix while calling system_path
Hi,
On Fri, 14 Sep 2012 11:14:13 +0800, liang xie wrote:
> memory leak fix while calling system_path
>
> Since v1: Remove an unnecessary null pointer check per Felipe's comments
> Since v2: Make system_path&perf_exec_path always return dynamically
> allocated string
>
> Signed-off-by: xieliang
> ---
> tools/perf/builtin-help.c | 12 +---
> tools/perf/builtin-script.c | 13 ++---
> tools/perf/perf.c |8 ++--
> tools/perf/util/config.c| 16 +---
> tools/perf/util/exec_cmd.c | 26 +++---
> tools/perf/util/exec_cmd.h |4 ++--
> tools/perf/util/help.c |6 --
> 7 files changed, 51 insertions(+), 34 deletions(-)
>
> diff --git a/tools/perf/builtin-help.c b/tools/perf/builtin-help.c
> index 6d5a8a7..180a5bd 100644
> --- a/tools/perf/builtin-help.c
> +++ b/tools/perf/builtin-help.c
> @@ -321,12 +321,13 @@ static void setup_man_path(void)
> {
> struct strbuf new_path = STRBUF_INIT;
> const char *old_path = getenv("MANPATH");
> + char *man_path = system_path(PERF_MAN_PATH);
I think the return value of system_path and perf_exec_path should be
checked since they can return NULL as strdup() does.
[snip]
> diff --git a/tools/perf/util/exec_cmd.c b/tools/perf/util/exec_cmd.c
> index 7adf4ad..1ace941 100644
> --- a/tools/perf/util/exec_cmd.c
> +++ b/tools/perf/util/exec_cmd.c
> @@ -9,17 +9,19 @@
> static const char *argv_exec_path;
> static const char *argv0_path;
>
> -const char *system_path(const char *path)
> +char *system_path(const char *path)
> {
> - static const char *prefix = PREFIX;
> - struct strbuf d = STRBUF_INIT;
> + char *new_path = NULL;
>
> if (is_absolute_path(path))
> - return path;
> + return strdup(path);
>
> - strbuf_addf(&d, "%s/%s", prefix, path);
> - path = strbuf_detach(&d, NULL);
> - return path;
> + new_path = malloc((strlen(PREFIX) + strlen(path) + 2));
> + if (!new_path)
> + die("malloc");
> +
> + sprintf(new_path, "%s/%s", PREFIX, path);
> + return new_path;
AFAIK strbuf allocates memory internally, so why this code is needed?
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question about LLC-load-misses event
Hi Chulmin, On Mon, 15 Oct 2012 22:31:34 +0900, Chulmin Kim wrote: > 2012-10-15 오후 10:07, Chulmin Kim 쓴 글: >> (perf command : perf stat -a -A -e LLC-loads -e LLC-load-misses -e >> instructions sleep 3) >> >> The problem is,, the bandwidth from STREAM benchmark does not match with >> the monitored value. >> >> e.g. >> I got 9395MB/s from Stream. >> >> "perf" shows 134,642,063 LLC-load-misses for 3 seconds. >> -> BW = ((# of events)/(3 seconds)) * 64 bytes / (1024*1024) = 2739MB/s >> In this equation, the term (64bytes) is for cache line size, and the >> term(1024*1024) is for (MB/s). >> >> Why does this mismatch occur? > In case of Oprofile, the value for a certain event represents the number > of the overflows which occur when the number of the event exceeds the > predefined value. > Is it a similar case with that? I guess not. And what's the result of the LLC-loads? AFAIK it counts all cache accesses including hits and misses. Did you calculate the bandwidth using the result of LLC-loads? I suspect the h/w *might* prefetches a couple of lines when cache-miss occurred, but I'm not sure. :) Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: perf top -z not working?
On Mon, 22 Oct 2012 07:12:19 -0600, David Ahern wrote: > On 10/22/12 5:50 AM, Ryan Johnson wrote: > It seems that `perf top -z' does not behave as advertized, at > least not on the 3.2.0-25 kernel (Ubuntu) that I'm running. The > man page states that it should "zero history across display > updates" but the counts still seem to accumulate (the total > samples reported rises monotonically) and processes still show up > in the display long after they have exited. Pressing `z' or `Z' > seems to have no effect, either. >>> Are you using the --tui or --stdio interface? Try with both and check if >>> it works in one of them, I bet the problem is with --tui. >> --stdio does the same, so I'll have to try updating my kernel like >> Chulmin suggested (haven't had time to do that yet) > > The kernel has nothing to do with the feature. From builtin-top.c, > this part is either not happening or more likely not happening > correctly. > > if (top->zero) > symbol__annotate_zero_histogram(symbol, top->sym_evsel->idx); > else > symbol__annotate_decay_histogram(symbol, top->sym_evsel->idx); Why symbol__annotate_zero_histogram only? AFAICS it only zeros sym_hist not hist_entry so meaningful just for annotation, right? Anyway, it's called iff top->sym_filter_entry is set. Not sure what's the intended behavior of the -z switch.. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] perf: proposed perf_event_open() manpage
Hi Vince, Great work! On Tue, 23 Oct 2012 11:35:13 -0400 (EDT), Vince Weaver wrote: > Hello > > attached is a proposed manpage for the perf_event_open() system call. > > I'd appreciate any review or comments, especially for the parts marked > as FIXME or "[To be documented]" > > This system call has a complicated interface and I'm sure I've missed > or glossed over various important features, so your feedback is needed and > appreciated. > > The eventual goal is to have this included with the Linux man-pages > project. [snip] > .BI "int perf_event_open(struct perf_event_attr *" hw_event , hw_event? Looks unusual.. how about 'attr'? > .BI "pid_t " pid ", int " cpu ", int " group_fd , > .BI "unsigned long " flags ); > .fi [snip] > .SS Arguments > .P > The argument > .I pid > allows events to be attached to processes in various ways. > If > .I pid > is 0, measurements happen on the current task, if > .I pid > is greater than 0, the process indicated by > .I pid > is measured, and if > .I pid > is less than 0, all processes are counted. Is that true? Shouldn't pid be -1? > > The > .I cpu > argument allows measurements to be specific to a CPU. > If > .I cpu > is greater than or equal to 0, > measurements are restricted to the specified CPU; > if > .I cpu > is \-1, the events are measured on all CPUs. > .P > Note that the combination of > .IR pid " == \-1" > and > .IR cpu " == \-1" > is not valid. > .P > A > .IR pid " > 0" s/>/>=/ ? > and > .IR cpu " == \-1" > setting measures per-process and follows that process to whatever CPU the > process gets scheduled to. > Per-process events can be created by any user. > .P > A > .IR pid " == \-1" > and > .IR cpu " >= 0" > setting is per-CPU and measures all processes on the specified CPU. > Per-CPU events need the > .B CAP_SYS_ADMIN > capability. Or value of perf_event_paranoid is less than 1. > .TP > .RB "dynamic PMU" > Since Linux 2.6.39, > .BR perf_event_open() > can support multiple PMUs. > To enable this, a value exported by the kernel can be used in the > .I type > field to indicate which PMU to use. > The value to use can be found in the sysfs filesystem: > there is a subdirectory per PMU instance under > .IR /sys/devices . /sys/bus/event_source/devices will be the right place. > In each sub-directory there is a > .I type > file whose content is an integer that can be used in the > .I type > field. > For instance, > .I /sys/devices/cpu/type /sys/bus/event_source/devices/cpu/type > contains the value for the core CPU PMU, which is usually 4. > .RE > [snip] > .TP > .IR sample_period ", " sample_freq > A "sampling" counter is one that generates an interrupt > every N events, where N is given by > .IR sample_period . > A sampling counter has > .IR sample_period " > 0." How about adding this here: "When an (overflow) interrupt generated, requested data (sample) would be recorded." > The > .I sample_type > field controls what data is recorded on each interrupt. > > .I sample_freq > can be used if you wish to use frequency rather than period. > In this case you set the > .I freq > flag. > The kernel will adjust the sampling period > to try and achieve the desired rate. > The rate of adjustment is a > timer tick. Is that true? I thought it'd be adjusted whenever overflow occures. > > > .TP > .I "sample_type" > The various bits in this field specify which values to include > in the overflow packets. I guess the overflow packets here means samples. It'd be better if we use a consistent word for specifying a thing. > They will be recorded in a ring-buffer, > which is available to user-space using > .BR mmap (2). > The order in which the values are saved in the > overflow packets as documented in the MMAP Layout subsection below; > it is not the > .I "enum perf_event_sample_format" > order. > .RS > .TP > .B PERF_SAMPLE_IP > instruction pointer > .TP > .B PERF_SAMPLE_TID > thread id > .TP > .B PERF_SAMPLE_TIME > time > .TP > .B PERF_SAMPLE_ADDR > address > .TP > .B PERF_SAMPLE_READ > [To be documented] It's for an event group to sample leader only. Values of other members will be read when an interrupt occurred on the leader. Jiri is working on it. > .TP > .B PERF_SAMPLE_CALLCHAIN > [To be documented] callchain (or stack backtrace) > .TP > .B PERF_SAMPLE_ID > [To be documented] unique(?) id for the opened event. > .TP > .B PERF_SAMPLE_CPU > [To be documented] cpu number > .TP > .B PERF_SAMPLE_PERIOD > [To be documented] event count > .TP > .B PERF_SAMPLE_STREAM_ID > [To be documented] > .TP > .B PERF_SAMPLE_RAW > [To be documented] additional data - usually for tracepoint events > .TP > .BR PERF_SAMPLE_BRANCH_STACK " (Since Linux 3.4)" > [To be documented] requested branch stack - only supported on intel machines which has LBR feature(?). See branch_sample_type. > .RE [snip] > .SS /proc/sys/kernel/perf_event_paranoid > > The > .I /proc/sys/kernel/perf_event_paranoid > file can be set t
Re: Multiple commands in perf 3.2.30 and 3.5.5 on Ubuntu 12 do not work
Hi Florin, On Tue, 13 Nov 2012 23:01:18 + (UTC), Florin Trofin wrote: > I mentioned in a previous post that "perf archive" command is not recognized > on > Ubuntu 12.04 (perf version 3.2.30) although it is listed in the --help > output. > I wanted to see if the issue was fixed in a later version so I tried > Ubuntu 12.10 (perf version 3.5.5) and it has the same problems: > archive is not recognized as a valid command, and other commands fail as well: > > $ perf timechart record sleep 2 > invalid or unsupported event: 'power:cpu_frequency' > Run 'perf list' for a list of valid events > > Another command that doesn't work: > > $ perf lock record sleep 2 > invalid or unsupported event: 'lock:lock_acquire' > Run 'perf list' for a list of valid events > > This makes me think that either perf is mostly broken in the new versions > or something is wrong on my machine (although installation went smoothly). > I installed perf by doing: > > $ sudo apt-get install linux-tools-common > $ sudo apt-get install linux-tools-3.5.0-17 > > Can somebody shed some light on this please? It looks like a problem of opening a tracepoint event. More specifically there's a problem in accessing debugfs. Even after changing /proc/sys/kernel/perf_events_paranoid to -1, I failed to record tracepoint events. $ ls /sys/kernel/debug ls: cannot open directory /sys/kernel/debug: Permission denied $ sudo ls -la /sys/kernel/debug | head -3 total 0 drwx--. 19 root root 0 Nov 6 10:38 . drwxr-xr-x. 8 root root 0 Nov 6 10:38 .. $ perf record -e sched:sched_switch invalid or unsupported event: 'sched:sched_switch' Run 'perf list' for a list of valid events I have no idea when it's changed, I used to be abled to access tracepoint events as a non-root user with the perf_events_paranoid setting. But this is failed on a recent kernel (w/ Fedora 17). $ uname -a Linux sejong.aot.lge.com 3.7.0-rc2+ #35 SMP PREEMPT Tue Nov 6 10:33:02 KST 2012 x86_64 x86_64 x86_64 GNU/Linux Anyways, running as root will solve your problem I guess. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Queries on using PERF tool
Hi, On Wed, 28 Nov 2012 15:02:43 +0900, Chulmin Kim wrote: > 2012-11-28 오후 2:47, Shahina Rabbani 쓴 글: >> Hi, >> >> I am a new user of PERF tool. I have few questions to ask about the PERF >> tool. >> Please help me with the answers. >> >> Q1. Is it possible to use PERF tool on a piece of code? Say i have a process >> P1 >> and the process has several functions F1, F2, F3. Is it possible to perform >> profilng only on F1 Function ?? >> > > As other profiling tools do, PERF also supports monitoring per > function (per SYMBOL). > > You can select the result related with the function you are interested in. It's not profiling the function only, it's just filtering the function in the whole result. You might want to use 'perf probe' command - on a recent kernel/perf tools support uprobe which is able to insert probe points dynamically to any user-level codes/functions. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PEBS event monitoring
Hi Chulmin, On Thu, 29 Nov 2012 15:08:16 +0900, Chulmin Kim wrote: > Hi, all. > > Sorry for consecutive basic questions. > > I am about to use PEBS monitoring of Intel CPU. (westmere) > > Let me elaborate pfmon example a bit. > > % pfmon --smpl-module=pebs -einstructions_retired --inv=1 > --counter-mask=1 --long-smpl-periods=266 -uk -- foo > # counts %self%cum code addr > 1976 70.67% 70.67% 0x004005e9 > 710 25.39% 96.07% 0x004005f1 >61 2.18% 98.25% 0x004005e0 >21 0.75% 99.00% 0x004005ed >10 0.36% 99.36% 0x004005f4 > 2 0.07% 99.43% 0x80583110 > 2 0.07% 99.50% 0x8024b4f8 > > As shown in the above, > I want to get the count number attached with address information. > > While the example is only for retired instruction event, I want the same > thing for memory event (mem_load_retired) using Perf. > > Is there any guide for this issue? Is this what you're looking for? (FYI, it's not merged yet) https://lkml.org/lkml/2012/11/21/295 Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Queries on using PERF tool
Hi Shahina, 2012-11-29 (목), 13:45 +0530, Shahina Rabbani: > Hi Namhyung Kim , > > > First of all Thanks for your mail. > I have some more doubts. Please help me. > > > Q1: when we are working with more than one CPU, there will be a shared > L2 cache for all the CPUs and each CPU will have its own L1-cache >If i want to monitor a event and i am using L1-cahce and > L2-caches from CPU1 and the same time if CPU2 is also trying to > monotora particular event and using L2- >cache. Then how the perf tool handles this situation. On a recent kernel and Intel cpus, it supports offcore and/or uncore events for that purpose AFAIK. Please check your cpu manuals. > > > Q2. Can you please list what are the architechtures it is supporting > at present. > > > Q3. Consider the case of Distributed systems, where the processors > are connected through the network and say i am trying to transmit data > over the TCP/IP stack. Is it > possible to monitor the data send at our end and data received > from the other end using the perf tool?? The perf tools work with pipe so that we might use nc/netcat for this. Only tested on a local machine: $ nc -l localhost 8282 | perf report -i - $ perf record -o - sleep 1 | nc localhost 8282 > > > Q4. when using perf record. Say i have got the data in perf.data file. > Say i am using this file to get some information and assume that > system crashes and the perf.data file is > in inconsistent state. when u reboot the system after the crash, > is it posssible to get the perf.data file safely.??? I doubt you can use the file safely. There's no guarantee when system crashed. Thanks, Namhyung > > > Q5. Say i am counting some samples depending on the clock. and assume > that i change the clock in between., Then the perf tool will be able > to understand the situation and count the samples depending on the old > and ne changed clocks or do we need to provide this information to > perf tool.?? how to handle this situation?? -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: perf with gnuplot
Hi Thorsten, On Wed, 23 Jan 2013 13:38:00 +0100, Thorsten Schuett wrote: > Hi, > > I record three different events for my test-program: > perf record -s -e cycles,instructions,LLC-load-misses ./test-program > > I want to plot the occurences of the different events over time, > i.e. x-axis is time and y-axis is event count. > > With > perf report -D > I can dump perf.data to ASCII. However, I could not figure out how to > extract different event types from the ASCII output. > > 0x1edb88 [0x30]: event: 9 > . > . ... raw event: size 48 bytes > . : 09 00 00 00 02 00 30 00 43 b6 2f e7 52 2b 00 00 ..0.C./.R+.. > . 0010: 2b 20 01 00 2f 20 01 00 2e 21 8e 48 b4 a9 26 00 + ../ ...!.H..&. > . 0020: f6 6d 00 00 00 00 00 00 6b 60 63 00 00 00 00 00 .m..k`c. > . > 10882640891486510 0x1edb88 [0x30]: PERF_RECORD_SAMPLE(IP, 2): > 73771/73775: 0x2b52e72fb643 period: 6512747 addr: 0 > > I figured out how to parse the timestamp, pid and pid and I guess > period says how often an event happened in the period. However I do > not know which event occured. Is this only encoded in the raw event or > am I missing something? > > Thorsten There's a patch proposed for this. I guess it'll likely get merged soon so that you can use it in v3.9? http://thread.gmane.org/gmane.linux.kernel/1427078/ Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Chronogram with pref ?
On Wed, 23 Jan 2013 14:17:03 +0100, Milian Wolff wrote: > On Wednesday 23 January 2013 09:49:16 dark_footix wrote: >> If I am interested to start a development of an graphic interface to visual >> the result, do you have some result of log which one I could parse ? which >> could be the formalism of the result ? >> >> What is the best way to develop this kind of feature ? >> Does it already exist ? > > I think what we need is a proper public perf library to parse its generated > data. That would then allow one to integrate Perf into KCacheGrind or similar > which would give one a really nice GUI. Though a timeline GUI similar to what > VTune offers would be very interesting as well. Afaik it does not exist yet. There's a gtk+ GUI support in the mainline perf tools. You can improve it as you wish. ;-) Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fw: Re: Re: Howto make perf probe work
> >HI, > >Please enable kprobe_event config option in the kernel and build the same > >and boot the board using it. Then please try to add event using perf probe > >command > > Thanks very much for your reply, and I already enable DEBUG_KPROBE_EVENT in > kernel. > I did success in "perf probe handle_mm_fault". > > But when i want to to "perf probe" other Kernel symbol, such as do_page_fault. > I came across other problems: > Added new event: > Failed to write event: Invalid argument > Error: Failed to add events. (-1) > And when i type perf probe page_fault_entry: > Kernel symbol 'page_fault_entry' not found. > Error: Failed to add events. (-2) > Please notice that "do_page_fault" and "page_fault_entry" are all Kernel > symbols, which canbe find in "/proc/kallsyms", but not recorgonized by perf > (or even kprobe). > Any idea for that? For some reason, do_page_fault() is marked as __kprobe on some arch which means it cannot be probed. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: perf event attrributes
Hi Chris, On Mon, 1 Apr 2013 16:09:50 +, Freehill Christopher-RAT wrote: > Andi, > > Thanks for the response. > > I am not familiar with "config/config1", but I infer from your message that I > would make folders in sysfs for different event groups (?) and then have a > file for each event that is a bit field that can be parsed. > > As an alternative, is there anything to prevent encoding the attributes in > the event ID itself? I think there are 64 bits to use. Some of those could be > interpreted in a way specific to the event. I can see advantages and > disadvantage to both. > > Both ways seem a little convoluted from a user point of view. Seems > like a more intuitive way would have been from the command line; ie, > provide a way to pass info from the command line that could be > interpreted in a way specific to the event. I'm sure that was probably > considered, and there is a good reason that method wasn't chosen, but > I do wonder... > > Can you point me to the Intel uncore drivers you mentioned? You can see it under /sys/bus/event_source/devices/uncore_imc_*/ on a recent kernel. There'll be the "format" and "events" directories. If you want to see the source, please go to: http://lxr.linux.no/#linux+v3.8.5/arch/x86/kernel/cpu/perf_event_intel_uncore.c Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fw: Re: Re: Howto make perf probe work
Hi, On Tue, 2 Apr 2013 17:11:01 +0800, >> For some reason, do_page_fault() is marked as __kprobe on some arch >> which means it cannot be probed. > > My kernel is runing on X86_64 arch, is there any chance for me to get the > do_page_fault() entry/exit work? nope, AFAIK. > Or How can i add a exit tracepoint for handle_mm_fault()? so I can calculate > the latency of that fault handle function? Try "perf probe -a entry=handle_mm_fault -a exit=handle_mm_fault%return" Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fw: Re: Re: Howto make perf probe work
Hi,
On Thu, 4 Apr 2013 01:28:34 +0800, OSDepend wrote:
>> On Tue, 2 Apr 2013 17:11:01 +0800, OSDepend wrote:
>> >> For some reason, do_page_fault() is marked as __kprobe on some arch
>> >> which means it cannot be probed.
>> >
>> > My kernel is runing on X86_64 arch, is there any chance for me to get the
>> > do_page_fault() entry/exit work?
>> nope, AFAIK.
> Is there any guide for us to decide which tracepoint (or other kernel symbol)
> canbe used, and which cannot?
> For some of the kallsyms cannot be used directly. Such as do_raw_spin_lock.
> perf probe -a test=do_raw_spin_lock
> Fatal: Kernel symbol 'do_raw_spin_lock' not found - probe not added.
Hmm.. it seems not, currently.
Maybe we can change perf to output the symbol was not able to be probed
after checking symbol address and it's between
__kprobes_text_{start,end}.
I'll take a look at it later.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: No tracepoint event in the perf list output
Hi Donitta, On Mon, 8 Apr 2013 09:51:32 + (UTC), Donitta wrote: > Hi, > > According to the perf documentation, when running "perf list" command we > should have all pre-defined events that could be hardware, software, hardware > cache, raw hardware event descriptor, hardware breakpoint or tracepoint event. > In my case, when I executed the perf list command I had all type of events > listed except the tracepoint event. > What does this mean? Do you have CONFIG_EVENT_TRACING enabled on your kernel? Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Changing frequency rate to perf mem
Hi Harald, On Thu, 24 Oct 2013 09:48:09 +0200, Harald Servat wrote: > On 24/10/13 07:12, Andi Kleen wrote: >> Harald Servat writes: >>> Unfortunately, this seems to break something and >>> perf segfaults often. Which is the most appropriate way to tune the >>> user frequency of perf mem? >> >> Best would be probably to fix it to pass through unknown >> options, then -F/-c could be just used. I'm not sure >> if this is possible easily with the git option parser. > > Sorry, I'm not sure what is the "git option parser" here. Just implementation details. The source code of the option parser came from the git project. > I think that this could be implemented extending the mem_options[] in > file builtin-mem.c lines 205-221. Or else, use 'perf record' directly as Andi suggested. > >> Alternatively you can just specify the command line perf mem record >> would specify directly to perf record, plus -c/-F $ perf record -Wd -e cpu/mem-loads/pp -F 200 -- ls $ perf mem report Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Intel PEBS Load Latency Measurement
Hi Manuel, On Mon, 28 Oct 2013 12:28:06 +0100, Manuel Selva wrote: > Hi, > > I am coming back on this subject after working on other stuff for > several weeks. Andi pointed me to the userland tool 'perf mem' > introduced in "recent" kernels (can't find the version) that is using > the kernel perf_event_open system call to profile memory accesses. > > I guess the answer to my question is in the code of this tool, but > before stepping deeper inside it, I wanted to ask you (Linux perf > experts) few questions, to be sure I am on the right track. > > For now, I just configured a perf_event_attr to perform sampling of > PERF_COUNT_HW_INSTRUCTIONS at a given period. Can you confirm than the > sample_period means "the kernel will generate a sample (with fields > asked through sample_type) every sample_period instructions ? Yes. > > Then after calling the perf_event_open system call I mmap the file > descriptor returned with an arbitrary size of X pages (with X = 1 + > 2^n). > > I then start recording events with ioctl on the file descriptor > returned by perf_event_open. I am now wondering how to access the > samples. My main concern is about the meaning of the data_head and > data_tail fields of the metadata page located at the beginning of the > memory mmaped. In understand that my samples are located just after > this metadata page, and that these head and tail pointers are used to > indicate where we are in the reading of the samples, is it correct ? Correct. > While reading samples, should I use/modify these head and tail > pointers, if yes what is the purpose of that ? The head is updated by kernel, you only need to update the tail after reading. Please see perf_record__mmap_read(). > > I am going now to look for the perf mem code, to try to understand > that from my side, but I am interested in any hint on the subject that > may help me. > > Many thanks in advance for your help, Hope this helps, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Intel PEBS Load Latency Measurement
Hi Manuel, I'm CC-ing Stephane who is the author of the perf mem tool. Stephane, could you please answer the questions below if you have some time? Thanks, Namhyung On Tue, 29 Oct 2013 10:12:39 +0100, Manuel Selva wrote: > Hi Namhyung, > > Many thanks for your answer and the function you pointed. I think I > now have all the required understanding of the perf_event_open syscall > to do what I want. > > I still have two questions regarding Intel (I am on a Westmere-Ep Xeon > X5650) Load latency feature and its usage by the perf mem tool. > > 1- In the Intel software developer guide we can read: "load operations > are randomly selected by hardware and tagged to carry information > related to data source locality and latency" I am wondering what does > it mean, are we doing sampling at two different levels ? First the > hardware chooses some load instructions to tag, and then each time X > (sampling period in events count specified by software) such tagged > instructions with a latency greater than a software specify threshold > we record a sample with some information. What is the sampling rate of > the hardware tagging mechanism, is it enough to get some interesting > results ? > > 2- How does the perf mem tool (with the load option) with of course > the help of the kernel uses this feature ? After a quick browsing of > the code, here is my understanding, is it correct ? > The PEBS load latency feature is enabled with the minimal possible > latency (3 cycles) to do sampling on all loads and with a given > default sampling period (x tagged load events with latency greater or > equal to 3). In addition to these "loads events" the perf mem tool > asks the kernel to record events about processes naming, and memory > mappings of code to be able to retrieve offline the source code > associated to instruction pointers present in samples. > > Thanks again for your help, > > Manu > > > 2013/10/29 Namhyung Kim >> >> Hi Manuel, >> >> On Mon, 28 Oct 2013 12:28:06 +0100, Manuel Selva wrote: >> > Hi, >> > >> > I am coming back on this subject after working on other stuff for >> > several weeks. Andi pointed me to the userland tool 'perf mem' >> > introduced in "recent" kernels (can't find the version) that is using >> > the kernel perf_event_open system call to profile memory accesses. >> > >> > I guess the answer to my question is in the code of this tool, but >> > before stepping deeper inside it, I wanted to ask you (Linux perf >> > experts) few questions, to be sure I am on the right track. >> > >> > For now, I just configured a perf_event_attr to perform sampling of >> > PERF_COUNT_HW_INSTRUCTIONS at a given period. Can you confirm than the >> > sample_period means "the kernel will generate a sample (with fields >> > asked through sample_type) every sample_period instructions ? >> >> Yes. >> >> > >> > Then after calling the perf_event_open system call I mmap the file >> > descriptor returned with an arbitrary size of X pages (with X = 1 + >> > 2^n). >> > >> > I then start recording events with ioctl on the file descriptor >> > returned by perf_event_open. I am now wondering how to access the >> > samples. My main concern is about the meaning of the data_head and >> > data_tail fields of the metadata page located at the beginning of the >> > memory mmaped. In understand that my samples are located just after >> > this metadata page, and that these head and tail pointers are used to >> > indicate where we are in the reading of the samples, is it correct ? >> >> Correct. >> >> >> > While reading samples, should I use/modify these head and tail >> > pointers, if yes what is the purpose of that ? >> >> The head is updated by kernel, you only need to update the tail after >> reading. Please see perf_record__mmap_read(). >> >> > >> > I am going now to look for the perf mem code, to try to understand >> > that from my side, but I am interested in any hint on the subject that >> > may help me. >> > >> > Many thanks in advance for your help, >> >> Hope this helps, >> Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Intel PEBS Load Latency Measurement
On Tue, 29 Oct 2013 14:20:09 +0100, Manuel Selva wrote: > One more thing I forgot to ask is clarification about the pid > parameter. According to Vince Weaver page: "If pid is 0, measurements > happen on the current thread, if pid is greater than 0, the process > indicated by pid is measured, and if pid is -1, all processes are > counted." and according to perf userland tool wiki page, it's possible > to attache to a specific thread with a -i option. As a consequence I > wonder how I can use the perf perf_event_sys_call to only count events > for a specific thread ? In the syscall's point of view, pid is actually tid AFAIK - so I works on the thread-basis not the process. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Does perf record support event multiplexing?
Hi AmirReza, On Mon, 27 Jan 2014 16:14:21 -0500, AmirReza Ghods wrote: > Thank you for your response, but that doesn't really answer my > question. I wanted to know why scaling of the event counts is > implemented in "perf stat" but NOT implemented in "perf record". I think the reason is "perf record" lacks enabled/running time information in the samples. > > As for caring about the exact sample count of perf report, I don't think > the relative usefulness of the values is a good reason to leave users > with some verifiably false results, and expect them to figure out why > they got them. I know some users, including myself, will be confused to > measure event counts differing (sometimes 300% in my experience) from > what they might expect. You might want to use "perf stat --no-scale" then. ;-) Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: perf not working for some commands?
Hi Jiri, On Tue, 28 Jan 2014 10:22:03 +0100, Jiri Olsa wrote: > [jolsa@krava perf]$ strace -fo out ./perf stat krava > Workload failed: No such file or directory > [jolsa@krava perf]$ cat out | grep exec You can also use "strace -f -e execve ./perf stat krava" :) Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Correctly handle symbols in VDSO
Hi Vladimir, On Tue, 1 Apr 2014 23:15:14 +0400, Vladimir Nikulichev wrote: > pert-report doesn't resolve function names in VDSO: > > $ perf report --stdio -g flat,0.0,15,callee --sort pid > ... > 8.76% > 0x7fff6b1fe861 > __gettimeofday > ACE_OS::gettimeofday() > ... > > In this case symbol values should be adjusted the same way as for > executables, relocatable objects and prelinked libraries. > > After fix: > > $ perf report --stdio -g flat,0.0,15,callee --sort pid > ... > 8.76% > __vdso_gettimeofday > __gettimeofday > ACE_OS::gettimeofday() > ... Tested-by: Namhyung Kim Just one question below.. > > --- > > perf tools: Adjust symbols in VDSO > > Signed-off-by: Vladimir Nikulichev > > diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c > index 3b7dbf5..9c8b23b 100644 > --- a/tools/perf/util/symbol-elf.c > +++ b/tools/perf/util/symbol-elf.c > @@ -6,6 +6,7 @@ > #include > > #include "symbol.h" > +#include "vdso.h" > #include > #include "debug.h" > > @@ -618,6 +619,8 @@ int symsrc__init(struct symsrc *ss, struct dso *dso, > const char *name, > GElf_Shdr shdr; > ss->adjust_symbols = (ehdr.e_type == ET_EXEC || > ehdr.e_type == ET_REL || > + (dso->symsrc_filename == NULL && Is this really needed? Just checking is_vdso_map() seems to work well for me. Did you have a specific reason to add it? Thanks, Namhyung > + is_vdso_map(dso->short_name)) || > elf_section_by_name(elf, &ehdr, &shdr, >".gnu.prelink_undo", >NULL) != NULL);-- > To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: recording rapl/power events
Hi Andi,
On Tue, 22 Apr 2014 03:17:56 -0700, Andi Kleen wrote:
> Adrien BAK writes:
>>
>> This looks promising, although I couldn't find any useful
>> documentation on this. Do you know if the perf userland tool allows
>> for this kind of slave-sampling or if I have to build my own tool
>> around the perf_event API ?
>
> perf record supports it (with :S), but none of the reporting tools
> unfortunately.
It seems it's what --group option of perf report is for?
$ perf record -e '{cycles,power/energy-pkg/}:S' -a sleep 1
$ perf report --group --stdio
Thanks,
Namhyung
>
> However keep in mind that very rapid sampling of RAPL is not
> likely to give useful results. The data only really makes
> sense over longer intervals.
>
> -Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Access to backtraces from user-space tracepoint callback in perf-script?
Hi Milian, On Wed, 07 May 2014 14:46:31 +0200, Milian Wolff wrote: > On Tuesday 29 April 2014 17:44:54 Milian Wolff wrote: >> Hello, >> >> today I played around with perf-script(-python) and custom tracepoints. What >> I could not figure out so far is how to print a backtrace from the python >> callback. Can someone explain me how this is done, or point me to the >> documentation for this? > > Ping? Could someone help me here please? As far as I know it's not possible currently.. I vaguely recall that there's a patch to support the feature but unfortunately it didn't get reviews.. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Loop block overhead
Hi lhmaster, On Wed, 7 May 2014 14:55:05 -0300, lhmaster wrote: > Thank you for the info. > > I researched a bit and found that srcline uses addr2line capabilities > to map memory addressed into source lines. Nevertheless, as I invoke > > $ perf report -s srcline, sys > > only the original mem addresses are printed. Should I pass some > special parameter for perf record to make it work? Nope. But you need to make sure that your binary was built with debuginfo and the binutils is available on your system. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Referencing perf?
Hi Harald and Vince, On Tue, 13 May 2014 10:24:06 -0400 (EDT), Vince Weaver wrote: > On Sat, 10 May 2014, Harald Servat wrote: > >> which is the appropriate way to reference perf in a publication? > > That's a good question. > > The original authors are T. Gleixner and I. Molnar, but they've never > published a real document about it. You could try citing the >tools/perf/design.txt document that comes with the Linux kernel, > or also the git commit 0793a61d4df8daeac6492dbf8d2f3e5713caae5e > from Thu Dec 4 2008 that introduced perf_event to the world. > > I'm not sure if there is an official way to cite a git commit. Maybe via web page of the commit? https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0793a61d4df8daeac6492dbf8d2f3e5713caae5e Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Where is main linux-perf IRC ?
Hi Taeung, On Wed, 02 Jul 2014 22:31:26 +0900, Taeung wrote: > Where is main linux-perf IRC ? > > I've failed finding main perf IRC though I try to find 'perf' IRC server. You can find it on #perf in OFTC . Please check www.oftc.net for details. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kprobe string
Hi Brendan,
On Wed, 16 Jul 2014 23:29:10 -0700, Brendan Gregg wrote:
> G'Day David,
>
> On Wed, Jul 16, 2014 at 9:41 PM, David Ahern wrote:
>>
>>
>> On 07/16/2014 06:51 PM, Brendan Gregg wrote:
>>>
>>> G'Day,
>>>
>>> I'm not sure where else to ask this; I don't think this functionality
>>> is in perf_events yet...
>>>
>>> kprobes is supposed to be able to handle string arguments, but I've
>>> not been able to find a single working example. I'm trying (on 3.16):
>>>
>>> # cd /sys/kernel/debug/tracing
>>> # echo 'r:getname getname $retval:string' > kprobe_events
>>> -bash: echo: write error: Invalid argument
>>> # echo 'p:myprobe do_sys_open %dx:string' > kprobe_events
>>> -bash: echo: write error: Invalid argument
>>>
>>> I'm following the syntax in Documentation/trace/kprobetrace.txt by
>>> Masami Hiramatsu, and it is recognizing "string". But I'm getting
>>> these errors:
>>>
>>> # dmesg | tail -4
>>> [98021.813560] string type has no corresponding fetch method.
>>> [98021.813564] Parse error at argument[0]. (-22)
>>> [98705.956199] string type has no corresponding fetch method.
>>> [98705.956203] Parse error at argument[0]. (-22)
>>>
>>> Anyone seen this work? I'm checking the source... Thanks in advance,
>>
>>
>> Have you seen this:
>> https://lkml.org/lkml/2014/6/19/698
>>
>
> Thanks! (I'm trying to keep up with all the perf messages on lkml, but
> missed this.)
>
> So, perf can already do this?? And it's the same syntax (":string") as
> kprobes?
>
> I just tried it out (on 3.14.5):
>
> # perf probe 'getname filename:string'
> Added new event:
> [...]
> # perf record -e probe:getname -a sleep 5
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.234 MB perf.data (~10241 samples) ]
> # perf script
> perf 13587 [000] 3576718.127120: probe:getname:
> (811bbd20)
> filename_string="/home/bgregg-testtest/libexec/perf-core/sleep"
> perf 13587 [000] 3576718.127142: probe:getname:
> (811bbd20) filename_string="/usr/local/sbin/sleep"
> perf 13587 [000] 3576718.127151: probe:getname:
> (811bbd20) filename_string="/usr/local/bin/sleep"
> perf 13587 [000] 3576718.127159: probe:getname:
> (811bbd20) filename_string="/usr/sbin/sleep"
> perf 13587 [000] 3576718.127170: probe:getname:
> (811bbd20) filename_string="/usr/bin/sleep"
> perf 13587 [000] 3576718.127180: probe:getname:
> (811bbd20) filename_string="/sbin/sleep"
> perf 13587 [000] 3576718.127189: probe:getname:
> (811bbd20) filename_string="/bin/sleep"
>sleep 13587 [000] 3576718.162025: probe:getname:
> (811bbd20) filename_string="/etc/ld.so.cache"
>sleep 13587 [000] 3576718.162057: probe:getname:
> (811bbd20) filename_string="/lib/x86_64-linux-gnu/libc.so.6"
> [...]
>
> Wow.
>
> Ok, so that's one solution! :-)
>
> It does need debuginfo, which is a bit of a problem here (the Netflix
> cloud, where instances are created and destroyed quickly, so they are
> optimized to be small).
>
> I did try just using the return value, which does work without
> debuginfo, however, the :string modifier doesn't work. Eg, trying:
>
> # perf probe 'getname%return $retval:string'
> Added new event:
> Failed to write event: Invalid argument
> Error: Failed to add events. (-1)
>
> $retval really is a string (well, it's a struct filename *, where the
> first member is a char *, so close enough), so perhaps perf could
> enhanced to allow this, and I'd be able to trace strings without
> debuginfo. (Unless there's another workaround.)
>
> So tools/perf/Documentation/perf-probe.txt does at least explain when
> :string won't work: "You can specify 'string' type only for the local
> variable or structure member which is an array of or a pointer to
> 'char' or 'unsigned char' type." I wonder if kprobes has this
> restriction as well.
Currently, "retval" and "reg" (and some other) fetch methods don't support
string
type. But I guess it can be easily worked around by using "deref" method.
Have you tried something like below (untested)?
# perf probe 'getname%return +0($retval):string'
Hmm.. maybe below (as you mentioned it's a char * in struct filename *).
# perf probe 'getname%return +0(+0($retval)):string'
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About use of dlsym()
Hi taeung, On Fri, 08 Aug 2014 15:29:26 +0900, taeung wrote: > Hello, perf hackers :-) > > I'm beginner in perf. > I'm analysing the sequence of function call and how it was written to > update 'report' of gtk view. > > This is a thread of a command 'perf report --gtk' > > 1. run_argv() > (in main of perf.c:534) > > 2. handle_internal_command() > (in run_argv of perf.c:420 ) > So far, I've thought this process is to filter what command and option is > > 3. cmd_report() > (in run_builtin of perf.c:319) by function pointer > > 4. setup_browser() > (in cmd_report of builtin-report.c:750) > > 5. setup_gtk_browser() > (in setup_browser of ui/setup.c:74) > > 6. perf_gtk__init() > (in setup_gtk_browser of ui/setup.c:32) > > about number 6, I have a question. > > In setup_gtk_browser of ui/setup.c: 28 ~ 32, > > 28 perf_ui_init = dlsym(perf_gtk_handle, "perf_gtk__init"); > 29 if (perf_ui_init == NULL) > 30 goto out_close; > 31 > 32 if (perf_ui_init() == 0) > 33 return 0; > 34 > > Why not call directly 'perf_gtk__init()' ? > Why call the function by function pointer(perf_ui_init) after it is > gotten by 'dlsym()' ? > Why use 'dlsym()' ? > Is it better than calling directly the function ? It was because many perf users wanted to reduce dependency in the main perf binary as they hardly/never use the GTK ui. Although it can be disabled with NO_GTK2=1 when invoking make, they're just too lazy to do that. :) Please see https://lkml.org/lkml/2013/8/4/154 . Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Power consumption measurements for ARM
Hi taeung, On Tue, 12 Aug 2014 17:20:45 +0900, taeung wrote: > Hi, perf hackers > > I have other question. > As I know, perf also supports RAPL(running average power limit ) > for power consumption measurements. > > And as I understand, the amount of power consumption is estimated > by using hardware performance counters and I/O models (sure, in > availableintel CPUs). > > And I've not found power consumption measurements for ARM (likeCortex-A9) > except for using tools like ARM Energy Probes and Linux EAPTools. > > But as I know , The Cortex-A9 Core Platform has dynamic scaling > ofvoltage and frequency. > (Dynamic Voltage and Frequency Scaling (DVFS)) > > Have you ever tried to measure power consumption on ARM using > thingslike DVFS? You may want to look at powertop - see https://01.org/powertop . > > and I also wonder how to use perf to measure power consumption on > available intel CPU. Please check https://lkml.org/lkml/2013/11/12/393 . Thanksm, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross compiling perf tool on ARM fails in yocto-linux environment
Hi Suresh, On Tue, 12 Aug 2014 18:04:10 + (UTC), Suresh Nagarajan wrote: > I am trying to cross-compile perf tool for ARM on x86 machine. > > > > > [snagarajan@moltar-76 perf]$ alias armmake='make CROSS_COMPILE=arm-linux- > gnueabihf- ARCH=arm' > [snagarajan@moltar-76 perf]$ PATH=~/gcc-linaro-arm-linux-gnueabihf-4.9- > 2014.07_linux/bin:$PATH > [snagarajan@moltar-76 perf]$ armmake install > BUILD: Doing 'make -j4' parallel build > > Auto-detecting system features: > ... backtrace: [ on ] > ... dwarf: [ on ] > ...fortify-source: [ on ] > ... glibc: [ on ] > ... gtk2: [ OFF ] > ... gtk2-infobar: [ OFF ] > ... libaudit: [ on ] > ...libbfd: [ on ] > ...libelf: [ on ] > ... libelf-getphdrnum: [ on ] > ... libelf-mmap: [ on ] > ... libnuma: [ OFF ] > ... libperl: [ on ] > ... libpython: [ on ] > ... libpython-version: [ on ] > ... libslang: [ OFF ] > ... libunwind: [ OFF ] > ... on-exit: [ on ] > ...stackprotector: [ on ] > ...stackprotector-all: [ on ] > ... timerfd: [ on ] > > config/Makefile:329: No libunwind found, disabling post unwind support. > Please install libunwind-dev[el] >= 1.1 > config/Makefile:368: slang not found, disables TUI support. Please install > slang-devel or libslang-dev > config/Makefile:381: GTK2 not found, disables GTK2 support. Please install > gtk2-devel or libgtk2.0-dev > config/Makefile:536: No numa.h found, disables 'perf bench numa mem' > benchmark, please install numa-libs-devel or libnuma-dev > FLEX util/pmu-flex.c > CC util/environment.o > CC util/event.o > CC util/evlist.o > In file included from util/callchain.h:8:0, > from util/hist.h:6, > from util/evsel.h:11, > from util/evlist.h:8, > from util/evlist.c:15: > util/symbol.h:17:20: fatal error: libelf.h: No such file or directory > #include > ^ > compilation terminated. > make[1]: *** [util/evlist.o] Error 1 > make[1]: *** Waiting for unfinished jobs > In file included from util/sort.h:11:0, > from util/event.c:5: > util/symbol.h:17:20: fatal error: libelf.h: No such file or directory > #include > ^ > compilation terminated. > make[1]: *** [util/event.o] Error 1 > make: *** [install] Error 2 > > > > > I have libelf.h file compiled for ARM, I tried replacing it in > /usr/include and also in ../arm-none-linux-gnueabi/libc/usr/include. > However, I face the same error. (I am not exactly sure about where the > compiler is looking for libelf.h) > > I noticed that this issue existed from 2012... Is this not fixed? Hmm.. don't know. You can try to build with setting EXTRA_CFLAGS and LDFLAGS to point your include and lib directory in the sysroot. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] perf Makefile: fix GNU-only grep usage
Hi John, You'd better to CC the lkml (linux-ker...@vger.kernel.org) for the perf patches to get reviewed by other developers. I'm copying to the list this time. On Mon, 25 Aug 2014 21:36:32 +0200, John Spencer wrote: > From efa79d5b7bc750369332a3a34442573af7b1b35c Mon Sep 17 00:00:00 2001 > From: John Spencer > Date: Mon, 25 Aug 2014 21:24:30 +0200 > Subject: [PATCH 1/2] perf Makefile: fix GNU-only grep usage > > this makes it work with non-GNU grep's as well. > > Signed-off-by: John Spencer Acked-by: Namhyung Kim Thanks, Namhyung > > --- > tools/perf/config/utilities.mak | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/perf/config/utilities.mak b/tools/perf/config/utilities.mak > index 4d985e0..7076a62 100644 > --- a/tools/perf/config/utilities.mak > +++ b/tools/perf/config/utilities.mak > @@ -132,7 +132,7 @@ endef > # > # Usage: bool-value = $(call is-absolute,path) > # > -is-absolute = $(shell echo $(shell-sq) | grep ^/ -q && echo y) > +is-absolute = $(shell echo $(shell-sq) | grep -q ^/ && echo y) > > # lookup > # -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] perf Makefile: default WERROR to off.
On Mon, 25 Aug 2014 21:37:08 +0200, John Spencer wrote: > From 4a72032828a6784d93f4becf723303a17d723544 Mon Sep 17 00:00:00 2001 > From: John Spencer > Date: Mon, 25 Aug 2014 21:25:43 +0200 > Subject: [PATCH 2/2] perf Makefile: default WERROR to off. > > Having WERROR on by default breaks build everywhere the author hasn't > tested so far; including musl libc which warns about wrong includes. > > The unsuspecting user will think there's something broken and only > if he's coureageuous enough to grep the Makefile infrastructure find > out that he may be able to get the build working with WERROR=0. > > OTOH with WERROR defaulting to off, anything will work for the user > and the maintainer can knowingly use WERROR=1 to do his test builds. I think it's intentionally turned on to fix any warnings in the first place. But yes, it might miss some non-popular systems tho.. How many errors/warnings do you see on your system (musl libc?). Any chance to post fixes instead? Thanks, Namhyung > > Signed-off-by: John Spencer > > --- > tools/perf/config/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile > index 1f67aa0..b1d639a 100644 > --- a/tools/perf/config/Makefile > +++ b/tools/perf/config/Makefile > @@ -102,7 +102,7 @@ ifeq ($(call get-executable,$(BISON)),) > endif > > # Treat warnings as errors unless directed not to > -ifneq ($(WERROR),0) > +ifeq ($(WERROR),1) >CFLAGS += -Werror > endif -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Perf event for Wall-time based sampling?
Hi Arnaldo and Millan, On Thu, 18 Sep 2014 16:17:13 -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Sep 18, 2014 at 06:37:47PM +0200, Milian Wolff escreveu: >> On Thursday 18 September 2014 12:57:45 Arnaldo Carvalho de Melo wrote: >> > Em Thu, Sep 18, 2014 at 05:26:33PM +0200, Milian Wolff escreveu: >> > > On Thursday 18 September 2014 11:51:24 Arnaldo Carvalho de Melo wrote: > >> > >> > > b) The callgraphs are really strange, imo. Different traces are printed >> > > with the same cost, which sounds wrong, no? See e.g. the multiple 44.44% >> > > traces in sched:sched_wakeup. > >> > Try using --no-children in the 'report' command line. > >> Nice, this is very useful. Many thanks! > > npo > >> > > c) Most of the traces point into the kernel, how can I hide these traces >> > > and only concentrate on the user-space? Do I have to grep manually for >> > > [.] ? I > >> > Oh well, for userspace you need to be aware of how callchains are >> > collected, i.e. if your binaries and libraries use >> > -fno-omit-frame-pointer, because if they do you will not get callchains >> > going into userspace, so you will need to specifically ask for 'DWARF' >> > callchains, from 'perf record' documentation: > >> I'm actually aware of that and I did add that option to my initial record >> call, sorry for not being clear here. > >> > >> > This has to be made automated, i.e. the tooling needs to figure out that >> > the binaries used do use %bp for optimization and automagically collect >> > DWARF, but till then, one needs to know about such issues and deal with >> > it. >> >> That would indeed be very welcome. There are multiple "defaults" in perf >> which >> I find highly confusing. The --no-children above e.g. could/should probably >> be >> the default, no? Similar, I find it extremely irritating that `perf report >> -g` > > It was, this is something we've actually been discussing recently: the > change that made --children be the default mode. That is why I added > Namhyung and Ingo to the CC list, so that they become aware of more > reaction to this change. Yeah, we should rethink about changing the default now. Actually I'm okay with the change, Ingo what do you think? > >> defaults to `-g fractal` and not `-g graph`. >> >> 100% foo >> 70% bar >> 70% asdf >> 30% lalala >> 30% baz >> >> is much harder to interpret than >> >> 100% foo >> 70% bar >> 49% asdf >> 21% lalala >> 30% baz I also agree with you. :) > > But the question then is if this is configurable, if not that would be a > first step, i.e. making this possible via some ~/.perfconfig change. Yes, we have record.call-graph and top.call-graph config options now so adding a new report.call-graph option should not be difficult. However I think it'd be better being call-graph.XXX as it can be applied to all other subcommands transparently. What about like below? [call-graph] mode = dwarf dump-size = 8192 print-type = fractal order = callee threshold = 0.5 print-limit = 128 sort-key = function > > Later we could advocate changing the default. Or perhaps provide some > "skins", i.e. config files that could be sourced into ~/.perfconfig so > that perf mimics the decisions of other profilers, with which people are > used to. > > Kinda like making mutt behave like pine (as I did a long time ago), even > if just for a while, till one gets used to the "superior" default way of > doing things of the new tool :-) > >> especially for more involved call chains. It took me quite some time to >> become >> aware of the ability to pass `-g graph` to get the desired output. >> KCacheGrind >> e.g. also defaults to something similar to `-g graph` and only optionally >> allows the user to get the "relative to parent" cost of `-g fractal`. >> >> > User space support is something that as you see, is still rough, we need >> > people like you trying it, but while it is rough, people tend to avoid >> > it... :-\ >> >> Yes. But already perf is extremely useful and I use it a lot. I'm also >> actively educating people about using it more. I've talked about it at last >> year's Akademy and Qt Developer Days, and again this year at a profiling >> workshop at Akademy. Please keep up the good work! > > Thanks a lot for doing that! > >> > > tried something like `perf report --parent "main"` but that makes no >> > > difference. > >> > > > I would recommend that you take a look at Brendan Greggs _excellent_ >> > > > tutorials at: > >> > > > http://www.brendangregg.com/perf.html > >> > > > He will explain all this in way more detail than I briefly skimmed >> > > > above. :-) > >> > > I did that already, but Brendan and the other available Perf >> > > documentation >> > > mostly concentrates on performance issues in the Kernel. I'm interested >> > > purely in the user space. Perf record with one of the hardware PMU events >> > > works nicely in that case, but one cannot use it to find locks&waits >> > > similar to wh
Re: Perf event for Wall-time based sampling?
2014-09-19 (금), 16:53 +0200, Milian Wolff: > On Friday 19 September 2014 11:33:40 Arnaldo Carvalho de Melo wrote: > > Em Fri, Sep 19, 2014 at 02:59:55PM +0900, Namhyung Kim escreveu: > > > Hi Arnaldo and Millan, > > > > > > On Thu, 18 Sep 2014 16:17:13 -0300, Arnaldo Carvalho de Melo wrote: > > > > Em Thu, Sep 18, 2014 at 06:37:47PM +0200, Milian Wolff escreveu: > > > >> That would indeed be very welcome. There are multiple "defaults" in > > > >> perf which I find highly confusing. The --no-children above e.g. > > > >> could/should probably be the default, no? Similar, I find it extremely > > > >> irritating that `perf report -g`> > > > > > It was, this is something we've actually been discussing recently: the > > > > change that made --children be the default mode. That is why I added > > > > Namhyung and Ingo to the CC list, so that they become aware of more > > > > reaction to this change. > > > > > > Yeah, we should rethink about changing the default now. Actually I'm > > > okay with the change, Ingo what do you think? > > > > > > >> defaults to `-g fractal` and not `-g graph`. > > > >> > > > >> 100% foo > > > >> > > > >> 70% bar > > > >> > > > >> 70% asdf > > > >> 30% lalala > > > >> > > > >> 30% baz > > > >> > > > >> is much harder to interpret than > > > >> > > > >> 100% foo > > > >> > > > >> 70% bar > > > >> > > > >> 49% asdf > > > >> 21% lalala > > > >> > > > >> 30% baz > > > > > > I also agree with you. :) > > > > > > > But the question then is if this is configurable, if not that would be a > > > > first step, i.e. making this possible via some ~/.perfconfig change. > > > > > > Yes, we have record.call-graph and top.call-graph config options now so > > > adding a new report.call-graph option should not be difficult. However > > > I think it'd be better being call-graph.XXX as it can be applied to all > > > > No problem, with sourcing being supported in ~/.perfconfig, we can have > > as many #include call-graph.XXX as needed, multiple levels of includes > > and all. > > > > > other subcommands transparently. > > > > > > What about like below? > > > > > > [call-graph] > > > > > > mode = dwarf > > > dump-size = 8192 > > > print-type = fractal > > > order = callee > > > threshold = 0.5 > > > print-limit = 128 > > > sort-key = function > > > > Milian, does this provide what you expect? How would we call this > > specific call-graph profile? > > print-type should be graph, not fractal. Otherwise it sounds good to me. But > how would one use it? I tried putting it into ~/.perfconfig, but apparently > my > 3.16.2-1-ARCH Perf does not support this feature yet? How/when would that > config be used? As soon as one does "perf record -g" (for mode and dump-size) > or "perf report" (for a perf.data with call graphs)? That would be very > useful! This is a proposal for new config items which can be included into the ~/.perfconfig file. You can change it as you want later and it should apply to default behavior of perf record -g and perf report. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] modified error code when perf_session__new() fail
Hi Taeung,
Please CC perf maintainers when you send a perf patch. I'm adding
Arnaldo who maintains tooling part and Jiri who suggested this change.
2014-09-17 (수), 17:31 +0900, taeung:
> Hi,
>
> I modified error code for the requirement as below.
>
> Author: taeung
> Date: Sat Sep 13 16:22:53 2014 +0900
>
> modified error code when perf_session__new() fail
>
> Because perf_session__new() could fail
> for more reasons than just ENOMEM,
> I modified error code(ENOMEM or EINVAL)
> into -1.
Hmm.. this seems you copied output of "git show" and send it via an
email client. I recommend you to use "git format-patch" and "git
send-email" later.
In addition, you forgot to add your Signed-off-by.
That being said I'm okay with the patch itself. Jiri, this is what you
wanted to do, right?
Thanks,
Namhyung
>
>
> diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
> index 1ec429f..81c9fda 100644
> --- a/tools/perf/builtin-annotate.c
> +++ b/tools/perf/builtin-annotate.c
> @@ -199,7 +199,7 @@ static int __cmd_annotate(struct perf_annotate *ann)
>
> session = perf_session__new(&file, false, &ann->tool);
> if (session == NULL)
> -return -ENOMEM;
> +return -1;
>
> machines__set_symbol_filter(&session->machines,
> symbol__annotate_init);
>
> diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
> index 9a5a035..3363dce 100644
> --- a/tools/perf/builtin-diff.c
> +++ b/tools/perf/builtin-diff.c
> @@ -683,7 +683,7 @@ static int __cmd_diff(void)
> d->session = perf_session__new(&d->file, false, &tool);
> if (!d->session) {
> pr_err("Failed to open %s\n", d->file.path);
> -ret = -ENOMEM;
> +ret = -1;
> goto out_delete;
> }
>
> diff --git a/tools/perf/builtin-evlist.c b/tools/perf/builtin-evlist.c
> index 66e12f5..0f93f85 100644
> --- a/tools/perf/builtin-evlist.c
> +++ b/tools/perf/builtin-evlist.c
> @@ -28,7 +28,7 @@ static int __cmd_evlist(const char *file_name, struct
> perf_attr_details *details
>
> session = perf_session__new(&file, 0, NULL);
> if (session == NULL)
> -return -ENOMEM;
> +return -1;
>
> evlist__for_each(session->evlist, pos)
> perf_evsel__fprintf(pos, details, stdout);
> diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
> index 9a02807..8dbdd13 100644
> --- a/tools/perf/builtin-inject.c
> +++ b/tools/perf/builtin-inject.c
> @@ -359,7 +359,7 @@ static int __cmd_inject(struct perf_inject *inject)
>
> session = perf_session__new(&file, true, &inject->tool);
> if (session == NULL)
> -return -ENOMEM;
> +return -1;
>
> if (inject->build_ids) {
> inject->tool.sample = perf_event__inject_buildid;
> diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
> index bef3376..b518f4b 100644
> --- a/tools/perf/builtin-kmem.c
> +++ b/tools/perf/builtin-kmem.c
> @@ -422,7 +422,7 @@ static int __cmd_kmem(void)
>
> session = perf_session__new(&file, false, &perf_kmem);
> if (session == NULL)
> -return -ENOMEM;
> +return -1;
>
> if (perf_session__create_kernel_maps(session) < 0)
> goto out_delete;
> diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
> index 43367eb..828e706 100644
> --- a/tools/perf/builtin-kvm.c
> +++ b/tools/perf/builtin-kvm.c
> @@ -1060,7 +1060,7 @@ static int read_events(struct perf_kvm_stat *kvm)
> .comm= perf_event__process_comm,
> .ordered_samples= true,
> };
> -struct perf_data_file file = {
> +struct perf_data_file file = {
> .path = kvm->file_name,
> .mode = PERF_DATA_MODE_READ,
> };
> @@ -1069,7 +1069,7 @@ static int read_events(struct perf_kvm_stat *kvm)
> kvm->session = perf_session__new(&file, false, &kvm->tool);
> if (!kvm->session) {
> pr_err("Initializing perf session failed\n");
> -return -EINVAL;
> +return -1;
> }
>
> if (!perf_session__has_traces(kvm->session, "kvm record"))
> @@ -1369,7 +1369,7 @@ static int kvm_events_live(struct perf_kvm_stat *kvm,
>*/
> kvm->session = perf_session__new(&file, false, &kvm->tool);
> if (kvm->session == NULL) {
> -err = -ENOMEM;
> +err = -1;
> goto out;
> }
> kvm->session->evlist = kvm->evlist;
> diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c
> index 6148afc..49f1e30 100644
> --- a/tools/perf/builtin-lock.c
> +++ b/tools/perf/builtin-lock.c
> @@ -862,7 +862,7 @@ static int __cmd_report(bool display_info)
> session = perf_session__new(&file, false, &eops);
> if (!session) {
> pr_err("Initializing perf session failed\n");
> -return -ENOMEM;
> +return -1;
> }
>
> if (!perf_session__has_traces(session, "lock record")
Re: Perf event for Wall-time based sampling?
On Fri, 19 Sep 2014 14:59:55 +0900, Namhyung Kim wrote:
> I'm also *very* interest in collecting idle/wait info using perf. Looks
> like we can somehow use sched:* tracepoints but it requires root
> privilege though (unless /proc/sys/kernel/perf_event_paranoid being -1).
>
> With that restriction however, we might improve perf sched (or even
> plain perf record/report) to provide such info.. David may have an
> idea. :)
I wrote a naive script called tasktime that uses task-clock and
sched:sched_switch events to record and report task execution and wait
time. Very lightly tested only..
The idea is that it counts time between context-switch and next
task-clock event as an wait time. Callchain is searched with a pattern
similar to the parent pattern to find the reason of the switch.
Please have a look and give some comments! :)
Thanks,
Namhyung
>From ff8497d91277c25d8c2c7688b7c056b38f799614 Mon Sep 17 00:00:00 2001
From: Namhyung Kim
Date: Mon, 22 Sep 2014 16:08:30 +0900
Subject: [PATCH] perf script: Introduce a new 'tasktime' python script
The tasktime script record and report task execution (and wait) time
using task-clock and sched:sched_switch events. When a task goes to a
context switch it searches callchain to have a certain pattern
(sys_.*|.*[^b][Ll]ock|page_fault) and prints with a "wait: " prefix.
If it fails to find the pattern in the callchain, it prints 'idle' or
'context-switch' depends on the next task scheduled.
Below is an example run of this script. You can see 'context-switch'
overhead is around 0.8% of total execution time in this workload.
Note that this script is not complete and posted only for discussion.
$ perf script record tasktime -- make clean all
$ perf script report tasktime | head -20
Overhead Command Shared Object Symbol
2.15% cc1 cc1 ht_lookup_with_hash
2.10% cc1 cc1 _cpp_lex_direct
1.78% cc1 libc-2.17.so _int_malloc
1.44% cc1 cc1 ggc_internal_alloc_stat
1.39% cc1 cc1 htab_find_slot_with_hash
0.85% cc1 cc1 bitmap_set_bit
0.84% cc1 cc1 lex_identifier
0.82% cc1 libc-2.17.so _int_free
0.80% cc1 context-switch
0.57% cc1 [kernel.kallsyms] __do_page_fault
0.55% cc1 cc1 cpp_get_token_1
0.54% cc1 cc1 df_note_compute
0.53% cc1 cc1 htab_find_with_hash
0.53% cc1 cc1 for_each_rtx_1
0.50% cc1 libc-2.17.so malloc_consolidate
0.48% cc1 cc1 grokdeclarator
0.46% aslibc-2.17.so __strncmp_sse42
0.46% asas4260905
Signed-off-by: Namhyung Kim
---
tools/perf/scripts/python/bin/tasktime-record | 3 +
tools/perf/scripts/python/bin/tasktime-report | 3 +
tools/perf/scripts/python/tasktime.py | 125 ++
3 files changed, 131 insertions(+)
create mode 100644 tools/perf/scripts/python/bin/tasktime-record
create mode 100644 tools/perf/scripts/python/bin/tasktime-report
create mode 100644 tools/perf/scripts/python/tasktime.py
diff --git a/tools/perf/scripts/python/bin/tasktime-record
b/tools/perf/scripts/python/bin/tasktime-record
new file mode 100644
index ..5aebcef93e55
--- /dev/null
+++ b/tools/perf/scripts/python/bin/tasktime-record
@@ -0,0 +1,3 @@
+#!/bin/bash
+perf record -gR -e task-clock -e sched:sched_switch $@
+
diff --git a/tools/perf/scripts/python/bin/tasktime-report
b/tools/perf/scripts/python/bin/tasktime-report
new file mode 100644
index ..a21f8dea15e7
--- /dev/null
+++ b/tools/perf/scripts/python/bin/tasktime-report
@@ -0,0 +1,3 @@
+#!/bin/bash
+# description: analyze task execution and wait time
+perf script $@ -s "$PERF_EXEC_PATH"/scripts/python/tasktime.py
diff --git a/tools/perf/scripts/python/tasktime.py
b/tools/perf/scripts/python/tasktime.py
new file mode 100644
index ..0d69d94cb31b
--- /dev/null
+++ b/tools/perf/scripts/python/tasktime.py
@@ -0,0 +1,125 @@
+# perf script event handlers, generated by perf script -g python
+# Licensed under the terms of the GNU GPL License version 2
+
+# The common_* event handler fields are the most useful fields common to
+# all events. They don't necessarily correspond to the 'common_*' fields
+# in the format files. Those fields not available as handler params can
+# be retrieved using Python functions of th
Re: [PATCH] modified error code when perf_session__new() fail
Hi Jiri, 2014-09-22 (월), 15:46 +0200, Jiri Olsa: > On Sun, Sep 21, 2014 at 12:44:55AM +0900, Namhyung Kim wrote: > > That being said I'm okay with the patch itself. Jiri, this is what you > > wanted to do, right? > > I have some vague memories about this.. any link to refresh my memory? ;-) This is it: https://lkml.org/lkml/2014/8/13/331 Thanks, Namhyung > but right, the change seems ok > > jirka -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] perf tools: modify error code when perf_session__new() fail.
Hi Taeung,
On Wed, 24 Sep 2014 10:33:37 +0900, Taeung Song wrote:
> Because perf_session__new() could fail for more reasons than just ENOMEM,
> I modified error code(ENOMEM or EINVAL) into -1.
>
> Signed-off-by: Taeung Song
Acked-by: Namhyung Kim
Thanks,
Namhyung
> ---
> tools/perf/builtin-annotate.c | 2 +-
> tools/perf/builtin-diff.c | 2 +-
> tools/perf/builtin-evlist.c| 2 +-
> tools/perf/builtin-inject.c| 2 +-
> tools/perf/builtin-kmem.c | 2 +-
> tools/perf/builtin-kvm.c | 4 ++--
> tools/perf/builtin-lock.c | 2 +-
> tools/perf/builtin-mem.c | 2 +-
> tools/perf/builtin-report.c| 2 +-
> tools/perf/builtin-script.c| 2 +-
> tools/perf/builtin-timechart.c | 2 +-
> tools/perf/builtin-top.c | 2 +-
> tools/perf/builtin-trace.c | 2 +-
> 13 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
> index d4da692..be59394 100644
> --- a/tools/perf/builtin-annotate.c
> +++ b/tools/perf/builtin-annotate.c
> @@ -340,7 +340,7 @@ int cmd_annotate(int argc, const char **argv, const char
> *prefix __maybe_unused)
>
> annotate.session = perf_session__new(&file, false, &annotate.tool);
> if (annotate.session == NULL)
> - return -ENOMEM;
> + return -1;
>
> symbol_conf.priv_size = sizeof(struct annotation);
> symbol_conf.try_vmlinux_path = true;
> diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
> index 190d0b6..a3ce19f 100644
> --- a/tools/perf/builtin-diff.c
> +++ b/tools/perf/builtin-diff.c
> @@ -683,7 +683,7 @@ static int __cmd_diff(void)
> d->session = perf_session__new(&d->file, false, &tool);
> if (!d->session) {
> pr_err("Failed to open %s\n", d->file.path);
> - ret = -ENOMEM;
> + ret = -1;
> goto out_delete;
> }
>
> diff --git a/tools/perf/builtin-evlist.c b/tools/perf/builtin-evlist.c
> index 66e12f5..0f93f85 100644
> --- a/tools/perf/builtin-evlist.c
> +++ b/tools/perf/builtin-evlist.c
> @@ -28,7 +28,7 @@ static int __cmd_evlist(const char *file_name, struct
> perf_attr_details *details
>
> session = perf_session__new(&file, 0, NULL);
> if (session == NULL)
> - return -ENOMEM;
> + return -1;
>
> evlist__for_each(session->evlist, pos)
> perf_evsel__fprintf(pos, details, stdout);
> diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
> index 3a62b6b..de99ca1 100644
> --- a/tools/perf/builtin-inject.c
> +++ b/tools/perf/builtin-inject.c
> @@ -460,7 +460,7 @@ int cmd_inject(int argc, const char **argv, const char
> *prefix __maybe_unused)
> file.path = inject.input_name;
> inject.session = perf_session__new(&file, true, &inject.tool);
> if (inject.session == NULL)
> - return -ENOMEM;
> + return -1;
>
> if (symbol__init(&inject.session->header.env) < 0)
> return -1;
> diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
> index 2376218..f295141 100644
> --- a/tools/perf/builtin-kmem.c
> +++ b/tools/perf/builtin-kmem.c
> @@ -698,7 +698,7 @@ int cmd_kmem(int argc, const char **argv, const char
> *prefix __maybe_unused)
>
> session = perf_session__new(&file, false, &perf_kmem);
> if (session == NULL)
> - return -ENOMEM;
> + return -1;
>
> symbol__init(&session->header.env);
>
> diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
> index f5d3ae4..fd84d47 100644
> --- a/tools/perf/builtin-kvm.c
> +++ b/tools/perf/builtin-kvm.c
> @@ -1062,7 +1062,7 @@ static int read_events(struct perf_kvm_stat *kvm)
> kvm->session = perf_session__new(&file, false, &kvm->tool);
> if (!kvm->session) {
> pr_err("Initializing perf session failed\n");
> - return -EINVAL;
> + return -1;
> }
>
> symbol__init(&kvm->session->header.env);
> @@ -1365,7 +1365,7 @@ static int kvm_events_live(struct perf_kvm_stat *kvm,
>*/
> kvm->session = perf_session__new(&file, false, &kvm->tool);
> if (kvm->session == NULL) {
> - err = -ENOMEM;
> + err = -1;
> goto out;
> }
> kvm->session->evlist = kvm->evlist;
> diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c
> index 92790ed..e7ec715 100
Re: [PATCH 1/1] perf tools: Fix Symbol Address for ET_DYN
Hi Tong,
Does a non-relocatable-dyn mean a prelink-ed dso?
Thanks,
Namhyung
On Wed, 24 Sep 2014 17:28:24 -0700, Tong Shen wrote:
> Gentle Ping :-)
>
> On Mon, Sep 15, 2014 at 11:06 AM, Tong Shen wrote:
>> Gentle ping :-)
>>
>> On Thu, Sep 11, 2014 at 1:38 PM, Arnaldo Carvalho de Melo
>> wrote:
>>> Em Thu, Sep 11, 2014 at 11:21:40AM -0700, Tong Shen escreveu:
Hi Arnaldo,
Thanks a lot for the comment!
I fixed the coding style and added a helper function with comments, as
you suggested :-)
See attachment.
>>>
>>> That is much better, I'm adding lkml to the CC list so that we can give
>>> other people the opportunity to chime in.
>>>
>>> - Arnaldo
>>>
On Thu, Sep 11, 2014 at 8:01 AM, Arnaldo Carvalho de Melo
wrote:
> Em Fri, Sep 05, 2014 at 11:38:02AM -0700, Tong Shen escreveu:
>> Hi linux-perf-users,
>>
>> It's actually a patch, and I didn't find a development mailing list
>> for perf, so I just post it here. If this is not the right place to
>
> You can post it here, but please add the maintainers to the CC list, so
> that we can more quickly see your message.
>
> Comments below:
>
>> post patches, could someone direct me to it? Thanks in advance!
>>
>> In tools/perf/util/symbol-elf.c, we don't adjust symbol address for
>> ET_DYN type of ELF files because we think ET_DYN is always
>> relocatable.
>>
>> But that's not necessarily true; there are some non-relocatable ET_DYN
>> ELF files. For those files, we should still adjust symbol address.
>
>> Suggested patch: (HTML subpart now allowed in this mailing list...)
>
>> +++ b/perf-3.12.0/tools/perf/util/symbol-elf.c
>> @@ -915,7 +915,10 @@ int dso__load_sym(struct dso *dso, struct map *map,
>
>> if ((used_opd && runtime_ss->adjust_symbols)
>> - || (!used_opd &&
>> syms_ss->adjust_symbols)) {
>> + || (!used_opd && syms_ss->adjust_symbols)
>> + || (syms_ss->ehdr.e_type == et_dyn
>> + && shdr.sh_addr != shdr.sh_offset
>> + && elf_sec__is_text(&shdr,
>> secstrs))) {
>
> Please try to follow kernel coding style in these tools, i.e. the &&
> should be at the end, the expression on each line should be aligned just
> after the opening parens.
>
> If, like in this case, you find something not following that style, take
> the opportunity to fix it :-)
>
> But back to your change, I'll have to look at this code further, just
> looking at the excerpt above I find it way too confusing, and your patch
> makes it even more so...
>
> Can you introduce some suitably named helper that has those extra
> conditions you're adding now and then add it to this conditional?
>
> I.e. make it somethine like:
>
> - if ((used_opd && runtime_ss->adjust_symbols)
> - || (!used_opd &&
> syms_ss->adjust_symbols)) {
> + if ((used_opd && runtime_ss->adjust_symbols) ||
> + (!used_opd && syms_ss->adjust_symbols) ||
> + syms__some_suitable_name(syms_ss, &shdr)) {
>
> And then add your explanation of these kinds of files as a comment over
> this new function, please?
>
>> pr_debug4("%s: adjusting symbol: st_value: %#"
>> PRIx64 " "
>> "sh_addr: %#" PRIx64 " sh_offset: %#"
>> PRIx64 "\n", __func__,
>> (u64)sym.st_value, (u64)shdr.sh_addr,
>
> Best regards,
>
> - Arnaldo
--
Best Regards, Tong Shen
>>>
diff --git a/perf-3.12.0/tools/perf/util/symbol-elf.c
b/perf-3.12.0/tools/perf/util/symbol-elf.c
index a9c829b..f9bd488 100644
--- a/perf-3.12.0/tools/perf/util/symbol-elf.c
+++ b/perf-3.12.0/tools/perf/util/symbol-elf.c
@@ -673,6 +673,27 @@ static u64 ref_reloc(struct kmap *kmap)
return 0;
}
+/**
+ * is_non_relocatable_dyn - check if ELF file is ET_DYN, but not
relocatable
+ * @ehdr: ELF header of the ELF file
+ * @shdr: a section header in the ELF file
+ *
+ * For ELF files with type ET_EXEC and ET_REL, we adjust symbol addresses
in
+ * symbol table in dso__load_sym() so that later we can always locate
symbols
+ * by sym.st_value + map_address_of_ELF_file.
+ *
+ * But ELF files with type ET_DYN may need adjusting as well, if they are
+ * not relocatable. There's no standard way to tell if an ELF file with
type
+ * ET_DYN is relocatable. One possible way to do that is checking if
+ * sh_addr == sh_off
Re: [PATCH 1/1] perf tools: Fix Symbol Address for ET_DYN
Hi Tong,
On Thu, 25 Sep 2014 22:53:22 -0700, Tong Shen wrote:
>> +/**
>> + * is_non_relocatable_dyn - check if ELF file is ET_DYN, but not
>> relocatable
>> + * @ehdr: ELF header of the ELF file
>> + * @shdr: a section header in the ELF file
>> + *
>> + * For ELF files with type ET_EXEC and ET_REL, we adjust symbol
>> addresses in
>> + * symbol table in dso__load_sym() so that later we can always locate
>> symbols
>> + * by sym.st_value + map_address_of_ELF_file.
>> + *
>> + * But ELF files with type ET_DYN may need adjusting as well, if they
>> are
>> + * not relocatable. There's no standard way to tell if an ELF file with
>> type
>> + * ET_DYN is relocatable. One possible way to do that is checking if
>> + * sh_addr == sh_offset for .text section.
>> + */
>> +static bool is_non_relocatable_dyn(GElf_Ehdr *ehdr, GElf_Shdr *shdr,
>> + Elf_Data *secstrs) {
>> + return ehdr->e_type == ET_DYN &&
>> +elf_sec__is_text(shdr, secstrs) &&
>> +shdr->sh_offset != shdr->sh_addr;
>> +}
>> +
>> int dso__load_sym(struct dso *dso, struct map *map,
>> struct symsrc *syms_ss, struct symsrc *runtime_ss,
>> symbol_filter_t filter, int kmodule)
>> @@ -914,8 +935,9 @@ int dso__load_sym(struct dso *dso, struct map *map,
>> goto new_symbol;
>> }
>>
>> - if ((used_opd && runtime_ss->adjust_symbols)
>> - || (!used_opd && syms_ss->adjust_symbols))
>> {
>> + if ((used_opd && runtime_ss->adjust_symbols) ||
>> + (!used_opd && syms_ss->adjust_symbols) ||
>> + is_non_relocatable_dyn(&ehdr, &shdr, secstrs)) {
>> pr_debug4("%s: adjusting symbol: st_value: %#"
>> PRIx64 " "
>> "sh_addr: %#" PRIx64 " sh_offset: %#"
>> PRIx64 "\n", __func__,
>> (u64)sym.st_value, (u64)shdr.sh_addr,
Hmm.. IIUC for normal dso (ET_DYN), shdr->offset == shdr->sh_addr for
text section right? And we always adjust ET_EXEC and ET_REL.. What
about always trying to adjust symbol address then? We may precalculate
adjust offset and subtracting it from symbol values. And the offset of
0 effectively means no adjust. This way we can simplify the logic IMHO.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What do zeroing of samples in 'perf top' mean ?
Hi Taeung, On Tue, 30 Sep 2014 12:19:41 +0900, taeung wrote: > Hi, > > I have two questions about 'zeroing of samples' in 'perf top'. > > I knew if I use 'perf top', I can see a performance counter profile in > real time. > But I can't find a difference between 'perf top -a' and 'perf top --zero'. > > After 'perf top' is run , I press key 'z' to toggle zeroing of samples. > But I don't know a difference between when I press key 'z' and before > I did it. > > 1. What is 'Zero history' ? > (I saw it in Documentation/perf-top.txt that '--zero' option is 'Zero > history across display updates.') > > 2. What do 'zeroing of samples' mean ? It seems that both questions are same. The way perf top works is collecting samples and cumulate them into the history (with decaying). So it basically shows current value + old value. With -z option, it won't use old values. And yes, one cannot easily find a difference between -z option and normal output. So we might need a visual cue as Arnaldo suggested earlier. Are you interested in implementing it? :) Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] perf top: Add a visual cue for toggle zeroing of samples
Hi Taeung,
On Sun, 5 Oct 2014 15:49:34 +0900, Taeung Song wrote:
> When 'perf top' is run, one can't easily find a difference
> between -z option and normal output.
> So I added a visual cue to know whether it is the zeroing or not.
[SNIP]
> +static int hists__browser_title(struct hists *hists,
> + struct hist_browser_timer *hbt,
> + char *bf,
> + size_t size)
You don't need to align arguments like this.
> {
> char unit;
> int printed;
> @@ -1256,6 +1268,14 @@ static int hists__browser_title(struct hists *hists,
> char *bf, size_t size)
> if (dso)
> printed += scnprintf(bf + printed, size - printed,
> ", DSO: %s", dso->short_name);
> + if (!is_report_browser(hbt)) {
> + struct perf_top *top = hbt->arg;
> +
> + if (top->zero)
> + printed += scnprintf(bf + printed, size - printed,
> + ", [z]", "");
It seems the final empty string can go away. And personally I'd like to
get rid of "," before "[z]" also.
Otherwise looks good to me. Could you please take a look at the stdio
output too?
Thanks,
Namhyung
> + }
> +
> return printed;
> }
>
> @@ -1267,12 +1287,6 @@ static inline void free_popup_options(char **options,
> int n)
> zfree(&options[i]);
> }
>
> -/* Check whether the browser is for 'top' or 'report' */
> -static inline bool is_report_browser(void *timer)
> -{
> - return timer == NULL;
> -}
> -
> /*
> * Only runtime switching of perf data file will make "input_name" point
> * to a malloced buffer. So add "is_input_name_malloced" flag to decide
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Collect Per thread event count using perf
Hi Hemendra, On Wed, 29 Oct 2014 02:03:36 + (UTC), Hemendra Rawat wrote: > Hi, > > I'm new to perf. I want to use perf to collect cpu-cycles spent in > each function for a multi-threaded program (Nasa Parallel Bench > marks OpenMP version). > > I'm using following commands to record and analyze the data. > > # perf record -s --call-graph=dwarf ./my-program 10 > # perf report -T --call-graph=graph > > But the TUI interface that opens up doesn't give information on a > per thread basis. It's all aggregate event count for each function. > I'm not sure whether i'm recording the data in the wrong way or > I'm missing something in the interpretation of perf output. Can > someone help me with this ? Any help will be highly appreciated. It seems only --stdio support the -T option (and recorded events have 'S' modifier?). What about using "perf report -s pid"? And I have a question to others: I always get confused with "perf record -s". It turns on the inherit_stat attribute, and what it does looks like sharing event value/stat with other tasks - but I maybe mis- understood something. Could anyone please explain it to me in more detail? Also it'd be better if the related man page also can be updated. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding cache misses and references to list of default events for perf stat?
Hi Andi and Milian,
On Tue, 04 Nov 2014 12:16:25 -0800, Andi Kleen wrote:
> Milian Wolff writes:
>
>> Hello all,
>>
>> could we have the cache-references,cache-misses events added to the list of
>> default events for perf stat? I think it is a very valuable metric for all
>> user-space applications.
>>
>> Currently, I run perf stat twice, once with the default events, and once with
>>
>> perf stat -e cache-references,cache-misses ...
>>
>> there is no easy way to append two events to the list of default events.
>>
>> So, what do you think?
>
> On most systems with only four counters it'll start multiplexing, which
> will give much worse results. Defaulting to non multiplexing is much
> better.
Anyway it has -d/--detailed option which can be specified up to 3 times.
# perf stat -ad sleep 1
Performance counter stats for 'system wide':
8021.100443 task-clock (msec) #8.013 CPUs utilized
[100.00%]
574 context-switches #0.072 K/sec
[100.00%]
10 cpu-migrations#0.001 K/sec
[100.00%]
61 page-faults #0.008 K/sec
153,639,037 cycles#0.019 GHz
[40.05%]
223,846,109 stalled-cycles-frontend # 145.70% frontend cycles
idle[40.14%]
205,555,693 stalled-cycles-backend# 133.79% backend cycles
idle[40.15%]
173,763,228 instructions #1.13 insns per cycle
#1.29 stalled cycles per
insn [50.12%]
34,553,334 branches #4.308 M/sec
[50.12%]
410,018 branch-misses #1.19% of all branches
[50.02%]
45,617,877 L1-dcache-loads #5.687 M/sec
[49.93%]
2,232,930 L1-dcache-load-misses #4.89% of all L1-dcache
hits [49.88%]
563,164 LLC-loads #0.070 M/sec
[39.92%]
240,780 LLC-load-misses # 42.75% of all LL-cache
hits[39.92%]
1.000997709 seconds time elapsed
Thanks,
Namhyung
>
> Reproducing the standard perf stat output isn't that difficult. It's
>
> perf stat -e
> task-clock,cs,migrations,page-faults,cycles,instructions,branches,branch-misses
>
> and then add more events. If you remove the bogus stalled-* events you
> have even two free counters.
>
> If you exceed four you should define appropiate groups with {}
>
> -Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sampling and reading
Hi Arnav, On Tue, 4 Nov 2014 20:27:08 + (UTC), Arnav wrote: > i am working on a project where i need to find program counters for every > 100M > instructions. > > i have used the following command to record the event > > perf record -e instructions -c 1 ./filename > > now, since counters are counted every 100M instructions, i read file using > 'perf report'. But i get results in some percentage form and not in numerical > numbers format. > > i wish to read the file and gather the perforamance counter statistics. > Plz suggest how to get the desired results. How about using perf report --show-total-period ? Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Size of perf data files
Hi Milian, On Wed, 26 Nov 2014 19:11:01 +0100, Milian Wolff wrote: > I tried this on a benchmark of mine: > > before: > [ perf record: Woken up 196 times to write data ] > [ perf record: Captured and wrote 48.860 MB perf.data (~2134707 samples) ] > > after, with dwarf,512 > [ perf record: Woken up 18 times to write data ] > [ perf record: Captured and wrote 4.401 MB perf.data (~192268 samples) ] > > What confuses me though is the number of samples. When the workload is equal, > shouldn't the number of samples stay the same? Or what does this mean? The > resulting reports both look similar enough. It's bogus - it just calculates the number of samples based on the file size (with fixed sample size). I think we should either show the correct number as we post-process samples for build-id detection or simply remove it. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Size of perf data files
Hi Arnaldo, On Thu, 27 Nov 2014 10:19:16 -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Nov 27, 2014 at 09:56:21AM +0900, Namhyung Kim escreveu: >> Hi Milian, >> >> On Wed, 26 Nov 2014 19:11:01 +0100, Milian Wolff wrote: >> > I tried this on a benchmark of mine: >> > >> > before: >> > [ perf record: Woken up 196 times to write data ] >> > [ perf record: Captured and wrote 48.860 MB perf.data (~2134707 samples) ] >> > >> > after, with dwarf,512 >> > [ perf record: Woken up 18 times to write data ] >> > [ perf record: Captured and wrote 4.401 MB perf.data (~192268 samples) ] >> > >> > What confuses me though is the number of samples. When the workload is >> > equal, >> > shouldn't the number of samples stay the same? Or what does this mean? The >> > resulting reports both look similar enough. >> >> It's bogus - it just calculates the number of samples based on the file >> size (with fixed sample size). I think we should either show the correct >> number as we post-process samples for build-id detection or simply >> remove it. > > Well, since we setup the perf_event_attr we could perhaps do a better > job at estimating this... In this case we even know how much stack_dump > we will take at each sample, that would be major culprit for the current > mis estimation. Also fp callchain and tracepoint events can lead the mis estimation IMHO. Thanks, Namhyung > > And yes, if we do the post processing, we can do a precise calculation. -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] perf tools: [uclibc] don't rely on glibc malloc working for sz 0
Hi Vineet,
On Tue, Jan 06, 2015 at 07:22:14PM +0530, Vineet Gupta wrote:
> When running perf on ARC (uClibc based userspace), ran into this issue
> ->8
> [ARCLinux]$ ./perf record ls
> bin etc perfsys
> debug initperf.data tmp
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.001 MB perf.data (~24 samples) ]
>
> [ARCLinux]$ ./perf report
> incompatible file format (rerun with -v to learn more)
> ->8
>
> The problem happens in the following call stack when zalloc is called
> with size zero
>
> glibc default / uClibc with MALLOC_GLIBC_COMPAT are OK, but not if that
> config option is not enabled.
>
> cmd_report
> perf_session__new
> perf_session__open
> perf_session__read_header
> read_attr(fd, header, &f_attr)
> nr_ids = f_attr.ids.size / sizeof(u64); <-- 0
> perf_evsel__alloc_id(vsel, 1, nr_ids)
> zalloc(ncpus * nthreads * sizeof(u64)) <-- 0
>
> header.c: read_attr()
>
> (gdb) p *f_attr
> $17 = {
> attr = {
> type = 0,
> size = 96,
> config = 0,
> {
> sample_period = 4000,
> sample_freq = 4000
> },
> ...
> ids = {
> offset = 104,
> size = 0 <--
> }
> }
Hmm.. okay. I think we don't need to allocate the id arrays when size
is 0. So perf_event__process_attr() will have the same problem IMHO.
How about this?
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 1e90c8557ede..1d826d63bc20 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -797,6 +797,9 @@ int perf_evsel__enable(struct perf_evsel *evsel, int ncpus,
int nthreads)
int perf_evsel__alloc_id(struct perf_evsel *evsel, int ncpus, int nthreads)
{
+ if (ncpus == 0 || nthreads == 0)
+ return 0;
+
if (evsel->system_wide)
nthreads = 1;
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] perf tools: [uclibc] provide stub for pthread_attr_setaffinity_np
On Tue, Jan 06, 2015 at 07:22:15PM +0530, Vineet Gupta wrote:
> uClibc Linuxthreads.old doesnt support pthread_attr_setaffinity_np()
> call
>
> ->8---
> CC bench/futex-hash.o
> CC bench/futex-wake.o
> bench/futex-hash.c: In function 'bench_futex_hash':
> bench/futex-hash.c:161:3: error: implicit declaration of function
> 'pthread_attr_setaffinity_np' [-Werror=implicit-function-declaration]
>ret = pthread_attr_setaffinity_np(&thread_attr, sizeof(cpu_set_t),
> &cpu);
>^
> bench/futex-hash.c:161:3: error: nested extern declaration of
> 'pthread_attr_setaffinity_np' [-Werror=nested-externs]
> ->8---
>
> Signed-off-by: Vineet Gupta
> ---
> tools/perf/bench/futex.h| 13 +
> tools/perf/config/Makefile | 6 ++
> tools/perf/config/feature-checks/Makefile | 4
> tools/perf/config/feature-checks/test-all.c | 5 +
> 4 files changed, 28 insertions(+)
It seems that you fotgot to add the real test file
(test-pthread_attr_setaffinity_np.c?) here..
Thanks,
Namhyung
>
> diff --git a/tools/perf/bench/futex.h b/tools/perf/bench/futex.h
> index 71f2844cf97f..7ed22ff1e1ac 100644
> --- a/tools/perf/bench/futex.h
> +++ b/tools/perf/bench/futex.h
> @@ -68,4 +68,17 @@ futex_cmp_requeue(u_int32_t *uaddr, u_int32_t val,
> u_int32_t *uaddr2, int nr_wak
>val, opflags);
> }
>
> +#ifndef HAVE_PTHREAD_ATTR_SETAFFINITY_NP
> +#include
> +static inline int pthread_attr_setaffinity_np(pthread_attr_t *attr,
> + size_t cpusetsize,
> + cpu_set_t *cpuset)
> +{
> + attr = attr;
> + cpusetsize = cpusetsize;
> + cpuset = cpuset;
> + return 0;
> +}
> +#endif
> +
> #endif /* _FUTEX_H */
> diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
> index 5d4b039fe1ed..6b59662136fa 100644
> --- a/tools/perf/config/Makefile
> +++ b/tools/perf/config/Makefile
> @@ -198,6 +198,7 @@ CORE_FEATURE_TESTS = \
> libpython-version \
> libslang\
> libunwind \
> + pthread-attr-setaffinity-np \
> stackprotector-all \
> timerfd \
> libdw-dwarf-unwind \
> @@ -226,6 +227,7 @@ VF_FEATURE_TESTS =\
> libelf-getphdrnum \
> libelf-mmap \
> libpython-version \
> + pthread-attr-setaffinity-np \
> stackprotector-all \
> timerfd \
> libunwind-debug-frame \
> @@ -301,6 +303,10 @@ ifeq ($(feature-sync-compare-and-swap), 1)
>CFLAGS += -DHAVE_SYNC_COMPARE_AND_SWAP_SUPPORT
> endif
>
> +ifeq ($(feature-pthread-attr-setaffinity-np), 1)
> + CFLAGS += -DHAVE_PTHREAD_ATTR_SETAFFINITY_NP
> +endif
> +
> ifndef NO_BIONIC
>$(call feature_check,bionic)
>ifeq ($(feature-bionic), 1)
> diff --git a/tools/perf/config/feature-checks/Makefile
> b/tools/perf/config/feature-checks/Makefile
> index 53f19b5dbc37..e9b99bb29348 100644
> --- a/tools/perf/config/feature-checks/Makefile
> +++ b/tools/perf/config/feature-checks/Makefile
> @@ -25,6 +25,7 @@ FILES= \
> test-libslang.bin \
> test-libunwind.bin \
> test-libunwind-debug-frame.bin \
> + test-pthread-attr-setaffinity-np.bin\
> test-stackprotector-all.bin \
> test-timerfd.bin\
> test-libdw-dwarf-unwind.bin \
> @@ -47,6 +48,9 @@ test-all.bin:
> test-hello.bin:
> $(BUILD)
>
> +test-pthread-attr-setaffinity-np.bin:
> + $(BUILD) -Werror
> +
> test-stackprotector-all.bin:
> $(BUILD) -Werror -fstack-protector-all
>
> diff --git a/tools/perf/config/feature-checks/test-all.c
> b/tools/perf/config/feature-checks/test-all.c
> index 652e0098eba6..6d4d09323922 100644
> --- a/tools/perf/config/feature-checks/test-all.c
> +++ b/tools/perf/config/feature-checks/test-all.c
> @@ -97,6 +97,10 @@
> # include "test-zlib.c"
> #undef main
>
> +#define main main_test_pthread_attr_setaffinity_np
> +# include "test-pthread_attr_setaffinity_np.c"
> +#undef main
> +
> int main(int argc, char *argv[])
> {
> main_test_libpython();
> @@ -121,6 +125,7 @@ int main(int argc, char *argv[])
> main_test_libdw_dwarf_unwind();
> main_test_sync_compare_and_swap(argc, argv);
> main_test_zlib();
> + main_test_pthread_attr_setaffinity_np();
>
> return 0;
> }
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from
Re: [PATCH 4/5] perf tools: [uclibc] don't rely on glibc malloc working for sz 0
On Sat, Jan 10, 2015 at 10:16:06AM +, Vineet Gupta wrote:
> On Thursday 08 January 2015 01:23 PM, Namhyung Kim wrote:
> > Hmm.. okay. I think we don't need to allocate the id arrays when size
> > is 0. So perf_event__process_attr() will have the same problem IMHO.
> > How about this?
> >
> >
> > diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> > index 1e90c8557ede..1d826d63bc20 100644
> > --- a/tools/perf/util/evsel.c
> > +++ b/tools/perf/util/evsel.c
> > @@ -797,6 +797,9 @@ int perf_evsel__enable(struct perf_evsel *evsel, int
> > ncpus, int nthreads)
> >
> > int perf_evsel__alloc_id(struct perf_evsel *evsel, int ncpus, int nthreads)
> > {
> > + if (ncpus == 0 || nthreads == 0)
> > + return 0;
> > +
> > if (evsel->system_wide)
> > nthreads = 1;
>
> Fine by me as I'm not too familiar with perf tools internals.
> So I need to spin a v2 for this or would you rather create a patch with me as
> Reported-by:
Please include this in your v2 and adds me as Suggested-by:
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] perf symbols: Define STT_GNU_IFUNC for glibc 2.9 and older.
Hi Vinson,
On Mon, Feb 09, 2015 at 04:29:37PM -0800, Vinson Lee wrote:
> From: Vinson Lee
>
> The token STT_GNU_IFUNC is not available with glibc 2.9 and older.
> Define this token if it is not already defined.
>
> This patch fixes this build errors with older versions of glibc.
>
> CC util/symbol-elf.o
> util/symbol-elf.c: In function ‘elf_sym__is_function’:
> util/symbol-elf.c:75: error: ‘STT_GNU_IFUNC’ undeclared (first use in this
> function)
> util/symbol-elf.c:75: error: (Each undeclared identifier is reported only once
> util/symbol-elf.c:75: error: for each function it appears in.)
> make: *** [util/symbol-elf.o] Error 1
>
> Cc: sta...@vger.kernel.org # 3.17+
> Signed-off-by: Vinson Lee
Acked-by: Namhyung Kim
Thanks,
Namhyung
> ---
> tools/perf/util/symbol-elf.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
> index 06fcd1b..eafee11 100644
> --- a/tools/perf/util/symbol-elf.c
> +++ b/tools/perf/util/symbol-elf.c
> @@ -69,6 +69,10 @@ static inline uint8_t elf_sym__type(const GElf_Sym *sym)
> return GELF_ST_TYPE(sym->st_info);
> }
>
> +#ifndef STT_GNU_IFUNC
> +#define STT_GNU_IFUNC 10
> +#endif
> +
> static inline int elf_sym__is_function(const GElf_Sym *sym)
> {
> return (elf_sym__type(sym) == STT_FUNC ||
> --
> 1.8.2.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: compile error : about declaration of ‘pthread_attr_setaffinity_np’
(Adding Arnaldo and Jiri to CC.) On Tue, Feb 24, 2015 at 06:02:51PM +0900, taeung wrote: > Hi, Namhyung Hi Taeung, > > After I pulled new changed source codes from 'perf/core' branch > (https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git) > ,when I compiled perf I've had a problem with error messages as below. > > (I'm using as below > system : Ubuntu 14.04.2 LTS 64-bit > kernel version : 3.13.0-40-generic) > > == > taeung ~/git/tip/tools/perf > :> make -j4 > > ...(omitted) > > In file included from bench/futex-hash.c:17:0: > bench/futex.h:73:19: error: conflicting types for > ‘pthread_attr_setaffinity_np’ > static inline int pthread_attr_setaffinity_np(pthread_attr_t *attr, >^ > In file included from bench/futex.h:72:0, > from bench/futex-hash.c:17: > /usr/include/pthread.h:407:12: note: previous declaration of > ‘pthread_attr_setaffinity_np’ was here > extern int pthread_attr_setaffinity_np (pthread_attr_t *__attr, > ^ This means it failed to find pthread_attr_setaffinity_np() on the feature test (so HAVE_PTHREAD_ATTR_SETAFFINITY_NP is not defined) but it's actually available on your system. > make[3]: *** [bench/futex-hash.o] Error 1 > make[2]: *** [bench] Error 2 > make[2]: *** Waiting for unfinished jobs > > ...(omitted) > > == > > But I modified 'tools/perf/config/feature-checks/Makefile' as Jirka said > (https://lkml.org/lkml/2015/1/12/216) > so I was able to compile perf. No Jiri's advice was to add -lpthread, not remove _GNU_SOURCE define. I guess adding -pthread instead of -lpthread might help.. > > > diff --git a/tools/perf/config/feature-checks/Makefile > b/tools/perf/config/feature-checks/Makefile > index b32ff33..42ac05a 100644 > --- a/tools/perf/config/feature-checks/Makefile > +++ b/tools/perf/config/feature-checks/Makefile > @@ -49,7 +49,7 @@ test-hello.bin: > $(BUILD) > > test-pthread-attr-setaffinity-np.bin: > - $(BUILD) -D_GNU_SOURCE -Werror -lpthread > + $(BUILD) -Werror -lpthread > > test-stackprotector-all.bin: > $(BUILD) -Werror -fstack-protector-all > > > Is this patch right ? I don't think so. You'd better to find out the reason of the failure in the feature test. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What do mean children of top ?
Hi Arnaldo and Taewoong,
On Tue, Mar 03, 2015 at 01:23:48PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Mar 03, 2015 at 02:04:47AM +0900, TaeWoong Song escreveu:
> > Hi, perf users
> >
> > About
> > The function perf_top_config() on builtin-top.c:
> > It depend on whether top.children is ’true’ in perfconfig
> > that whether ‘symbol_conf.cumulate_callchain’ is ’true’ or not.
> > (when ‘top' only work with ‘—call-graph' )
> >
> > The output of ’top —call-graph fp’ is changed depending on a boolean value
> > of ‘symbol_conf.cumulate_callchain’.
> >
> > Do mean children of top relationship of calling functions which are parents
> > or children ?
> > Linked-ring of invoking functions ?
> >
> > I wanna exactly explain the effect of ‘top.children’ in perfconfig.
> > Can anybody tell me the different between true and false on top.children ?
> >
> > If anybody a bit give hints me, I’ll appreciate it.
The effect of top.children is same as report.children but just for perf top.
The children here means that functions called from another function.
Let me give you an example:
void foo(void) {
/* do something */
}
void bar(void) {
/* do something */
foo();
}
int main(void) {
bar()
return 0;
}
In this case 'foo' is a child of 'bar', and 'bar' is an immediate
child of 'main' so 'foo' also is a child of 'main'. In other words,
'main' is a parent of 'foo' and 'bar'. and 'bar' is a parent of 'foo'.
When you record with callchain you'll see something like this:
Overhead Symbol
.
60.00% foo
|
--- foo
bar
main
__libc_start_main
40.00% bar
|
--- bar
main
__libc_start_main
These percentage are 'self' overhead that came from the samples of the
function themselves. If you use --children, the overhead of children
will be add to all of parents to calculate 'children' overhead. In
this case we'll see somethink like below:
Children Self Symbol
100.00% 0.00% __libc_start_main
|
--- __libc_start_main
100.00% 0.00% main
|
--- main
__libc_start_main
100.00%40.00% bar
|
--- bar
main
__libc_start_main
60.00%60.00% foo
|
--- foo
bar
main
__libc_start_main
The first percentage is the children overhead and second is the self
overhead. As you can see, the children overhead is a sum of the self
overhead and all (self) overhead of children. It gives you an higher
level view which function (including children) consumes cpu cycles (or
other event) more. And with '--call-graph caller', you'll see which
children are called from this function.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] perf tui: Annotate entries in callchains
Hi Stephane, On Fri, Mar 20, 2015 at 02:12:30PM -0700, Stephane Eranian wrote: > On Fri, Mar 20, 2015 at 2:07 PM, Arnaldo Carvalho de Melo > wrote: > > Em Fri, Mar 20, 2015 at 05:39:22PM -0300, Arnaldo Carvalho de Melo escreveu: > >> Em Fri, Mar 20, 2015 at 10:15:53AM -0700, Stephane Eranian escreveu: > >> > On Thu, Mar 19, 2015 at 5:39 PM, Arnaldo Carvalho de Melo > >> > wrote: > >> > > On Mar 19, 2015 9:34 PM, "Stephane Eranian" wrote: > >> > >> On Thu, Mar 19, 2015 at 3:58 PM, Arnaldo Carvalho de Melo > >> > >> wrote: > >> > >> > This patch, together with what is in my perf/core branch, > >> > >> > should > >> > >> > implement that feature we talked about recently, i.e. to allow > >> > >> > annotating entries in callchains, please take a look at see if you > >> > >> > think > >> > >> > it is ok, > > > >> > >> I tried on tip.git and a simple example. It does what I wanted. > >> > >> I will try on more complex test cases. > >> > >> Thanks for implementing this quickly. > > > >> > > Thanks for testing, please let us know if you have further suggestions, > > > >> > Ok, it does not work. > > > > Are you sure? I just tried, take a look at: > > > > http://vger.kernel.org/~acme/perf-report-annotate-callchain-entries-in-multiple-DSOs-in-the-same-hist_entry.png > > > > In there you will see that in the unmap_single_vma case there are > > callchains that pass thru multiple DSOs in userspace (I used --call > > dwarf in 'perf record') and those are marked as having > > samples/annotation and when I go to those, pressing 'a' after moving the > > cursor to it and it works as expected... > > > > Do you have some specific example I could try? > > > I tried on an example I cannot share. > But I am guessing you could reproduce with a test which calls a libc > or libm function > heavily form multiple callers in the main program. > Example: >- pow() >50% foo() [main.c] >50% bar() [main.c] > > If I move the cursor line to foo() and annotate foo() is shows me the > code of pow(). Did you play with acme/perf/core not tip/perf/core? I got same problem but then I realize it's not the Arnaldo's tree. When I changed to acme/perf/core the problem disappeared. :) But unfortunately I got this segfault instead.. namhyung@sejong:perf$ perf report perf: Segmentation fault backtrace perf[0x506e5b] /usr/lib/libc.so.6(+0x33540)[0x7fa3eb90a540] perf[0x47b39c] perf(disasm_line__free+0x58)[0x47c178] perf(symbol__tui_annotate+0x2f3)[0x4fe683] perf[0x503773] perf(perf_evlist__tui_browse_hists+0x94)[0x505b44] perf(cmd_report+0x18f0)[0x436890] perf[0x47a793] perf(main+0x60a)[0x427c7a] /usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7fa3eb8f7800] perf(_start+0x29)[0x427d99] [0x0] namhyung@sejong:perf$ addr2line -e `which perf` 0x506e5b /home/namhyung/project/linux/tools/perf/ui/tui/setup.c:106 namhyung@sejong:perf$ addr2line -e `which perf` 0x47b39c /home/namhyung/project/linux/tools/perf/util/annotate.c:33 Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] perf annotate: Set the input file name after parsing options.
Hi Roland,
On Thu, Mar 19, 2015 at 01:26:09PM -0400, Roland Grunberg wrote:
> The input file name should be set after parse_options has been called if
> the '-i' option is to have any effect.
>
> Signed-off-by: Roland Grunberg
Acked-by: Namhyung Kim
Thanks,
Namhyung
> ---
>
> Not registered to the referenced lists so feel free to CC.
>
> The input file option for perf-annotate seems to be broken and will always
> default to 'perf.data'. The perf_data_file path field is being set before
> parse_options has initialized input_name.
>
> Current Behaviour :
> $ perf record -o datafile uname
> Linux
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.007 MB datafile (~322 samples) ]
> $ file datafile
> datafile: data
> $ perf annotate --stdio -i datafile
> failed to open perf.data: No such file or directory (try 'perf record' first)
>
> Expected Behaviour :
> The 'perf-annotate' call should run against the specified input file.
>
> tools/perf/builtin-annotate.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
> index 747f861..78489bc 100644
> --- a/tools/perf/builtin-annotate.c
> +++ b/tools/perf/builtin-annotate.c
> @@ -283,7 +283,6 @@ int cmd_annotate(int argc, const char **argv, const char
> *prefix __maybe_unused)
> },
> };
> struct perf_data_file file = {
> - .path = input_name,
> .mode = PERF_DATA_MODE_READ,
> };
> const struct option options[] = {
> @@ -333,6 +332,8 @@ int cmd_annotate(int argc, const char **argv, const char
> *prefix __maybe_unused)
>
> argc = parse_options(argc, argv, options, annotate_usage, 0);
>
> + file.path = input_name;
> +
> if (annotate.use_stdio)
> use_browser = 0;
> else if (annotate.use_tui)
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] perf tools: Work around lack of sched_getcpu in glibc < 2.6.
Hi Vinson,
On Mon, Mar 23, 2015 at 12:09:16PM -0700, Vinson Lee wrote:
> From: Vinson Lee
>
> This patch fixes this build error with glibc < 2.6.
>
> CC util/cloexec.o
> cc1: warnings being treated as errors
> util/cloexec.c: In function ‘perf_flag_probe’:
> util/cloexec.c:24: error: implicit declaration of function
> ‘sched_getcpu’
> util/cloexec.c:24: error: nested extern declaration of ‘sched_getcpu’
> make: *** [util/cloexec.o] Error 1
>
> Cc: sta...@vger.kernel.org # 3.18+
> Signed-off-by: Vinson Lee
Acked-by: Namhyung Kim
Thanks,
Namhyung
> ---
> tools/perf/util/cloexec.c | 6 ++
> tools/perf/util/cloexec.h | 6 ++
> 2 files changed, 12 insertions(+)
>
> diff --git a/tools/perf/util/cloexec.c b/tools/perf/util/cloexec.c
> index 6da965b..85b5238 100644
> --- a/tools/perf/util/cloexec.c
> +++ b/tools/perf/util/cloexec.c
> @@ -7,6 +7,12 @@
>
> static unsigned long flag = PERF_FLAG_FD_CLOEXEC;
>
> +int __weak sched_getcpu(void)
> +{
> + errno = ENOSYS;
> + return -1;
> +}
> +
> static int perf_flag_probe(void)
> {
> /* use 'safest' configuration as used in perf_evsel__fallback() */
> diff --git a/tools/perf/util/cloexec.h b/tools/perf/util/cloexec.h
> index 94a5a7d..6c2 100644
> --- a/tools/perf/util/cloexec.h
> +++ b/tools/perf/util/cloexec.h
> @@ -3,4 +3,10 @@
>
> unsigned long perf_event_open_cloexec_flag(void);
>
> +#ifdef __GLIBC_PREREQ
> +#if !__GLIBC_PREREQ(2, 6)
> +extern int sched_getcpu(void) __THROW;
> +#endif
> +#endif
> +
> #endif /* __PERF_CLOEXEC_H */
> --
> 1.8.2.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is 'web--browse' on builtin-help.c ?
Hi Taeung,
On Wed, Dec 02, 2015 at 12:46:40PM +0900, Taeung Song wrote:
> Hi, all
>
> I’m checking perf-help subcommand and config ‘help.format’.
> source code for them contain functionality for info and web
> but functionality for info and web didn’t work well. ( there isn’t problems
> about ‘man’ )
>
> So, I’m trying to fix the bugs.
> There is a function ‘open_html()’ on builtin-help.c as below.
>
> 408 static void open_html(const char *path)
> 409 {
> 410 execl_perf_cmd("web--browse", "-c", "help.browser", path, NULL);
> 411 }
>
> excel_perf_cmd() function lastly call execvp(“perf”, (char **)nargv)
> and then error messages like.
>
> perf: 'web--browse' is not a perf-command.
>
> Is this leftover from git source code ?
I think so, there's git-web--browse script to find and run available
web browser on a system.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH perf/core 00/22] perf refcnt debugger API and fixes
Hi Arnaldo and Masami,
On Wed, Dec 09, 2015 at 10:41:38AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Dec 09, 2015 at 11:10:48AM +0900, Masami Hiramatsu escreveu:
> > In this series I've also tried to fix some object leaks in perf top
> > and perf stat.
> > After applying this series, this reduced (not vanished) to 1/5.
> >
> > # ./perf top --stdio
> > q
> > exiting.
> > REFCNT: BUG: Unreclaimed objects found.
> > REFCNT: Total 866 objects are not reclaimed.
> > "dso" leaks 213 objects
> > "map" leaks 624 objects
> > "comm_str" leaks 12 objects
> > "thread" leaks 9 objects
> > "map_groups" leaks 8 objects
> > To see all backtraces, rerun with -v option
> >
> >
> > Actually, I'm still not able to fix all of the bugs. It seems that
> > hists has a bug that hists__delete_entries doesn't delete all the
> > entries because some entries are on hists->entries but others on
> > hists->entries_in. And I'm not so sure about hists.c.
> > Arnaldo, would you have any idea for this bug?
>
> I'll will audit the hists code, its all about collecting new entries
> into an rbtree to then move the last batch for merging with the
> previous, decayed ones while continuing to process a new batch in
> another thread.
Right. After processing is done, hist entries are in both of
hists->entries and hists->entries_in (or hists->entries_collapsed).
So I guess perf report does not have leaks on hists.
But for perf top, it's possible to have half-processed entries which
are only in hists->entries_in. Eventually they will go to the
hists->entries and get freed but they cannot be deleted by current
hists__delete_entries(). If we really care deleting all of those
half-processed entries, how about this?
Thanks,
Namhyung
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index fd179a068df7..08396a7fea23 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -270,6 +270,8 @@ static void hists__delete_entry(struct hists *hists, struct
hist_entry *he)
if (sort__need_collapse)
rb_erase(&he->rb_node_in, &hists->entries_collapsed);
+ else
+ rb_erase(&he->rb_node_in, hists->entries_in);
--hists->nr_entries;
if (!he->filtered)
@@ -1589,11 +1591,33 @@ int __hists__init(struct hists *hists)
return 0;
}
+static void hists__delete_remaining_entries(struct rb_root *root)
+{
+ struct rb_node *node;
+ struct hist_entry *he;
+
+ while (!RB_EMPTY_ROOT(root)) {
+ node = rb_first(root);
+ rb_erase(node, root);
+
+ he = rb_entry(node, struct hist_entry, rb_node_in);
+ hist_entry__delete(he);
+ }
+}
+
+static void hists__delete_all_entries(struct hists *hists)
+{
+ hists__delete_entries(hists);
+ hists__delete_remaining_entries(&hists->entries_in_array[0]);
+ hists__delete_remaining_entries(&hists->entries_in_array[1]);
+ hists__delete_remaining_entries(&hists->entries_collapsed);
+}
+
static void hists_evsel__exit(struct perf_evsel *evsel)
{
struct hists *hists = evsel__hists(evsel);
- hists__delete_entries(hists);
+ hists__delete_all_entries(hists);
}
static int hists_evsel__init(struct perf_evsel *evsel)
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
