* perf script doesn't dump a normal call trace
@ 2018-11-02 6:36 Xin Long
2018-11-02 10:26 ` Jiri Olsa
0 siblings, 1 reply; 7+ messages in thread
From: Xin Long @ 2018-11-02 6:36 UTC (permalink / raw)
To: LKML, linux-perf-users, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Jiri Olsa,
Namhyung Kim
On upstream kernel(4.19) or RHEL-8 kernel(4.18.0):
# perf record -e 'skb:consume_skb' -ag
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.612 MB perf.data (634 samples) ]
# perf script
swapper 0 [009] 274370.117711: skb:consume_skb: skbaddr=0xffff962c591d5b00
ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
kworker/9:1-eve 926 [009] 274370.117729: skb:consume_skb:
skbaddr=0xffff962c591d5b00
ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
kworker/9:1-eve 926 [009] 274370.117732: skb:consume_skb:
skbaddr=0xffff962c591d4900
ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
swapper 0 [009] 274370.145528: skb:consume_skb: skbaddr=0xffff962c591d4900
ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
kworker/9:1-eve 926 [009] 274370.145545: skb:consume_skb:
skbaddr=0xffff962c591d4900
ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
kworker/9:1-eve 926 [009] 274370.145547: skb:consume_skb:
skbaddr=0xffff962c591d5b00
ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
swapper 0 [009] 274370.173443: skb:consume_skb: skbaddr=0xffff962c591d5b00
ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
On RHEL-7 kernel(3.10.0):
# perf record -e 'skb:consume_skb' -ag
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.170 MB perf.data (214 samples) ]
# perf script
swapper 0 [001] 69006.726193: skb:consume_skb: skbaddr=0xffff917db9647900
7fffb3425a00 consume_skb ([kernel.kallsyms])
7fffb34ba3cb arp_process ([kernel.kallsyms])
7fffb34bad65 arp_rcv ([kernel.kallsyms])
7fffb343b6d9 __netif_receive_skb_core ([kernel.kallsyms])
7fffb343b9d8 __netif_receive_skb ([kernel.kallsyms])
7fffb343ba60 netif_receive_skb_internal ([kernel.kallsyms])
7fffb343c6e8 napi_gro_receive ([kernel.kallsyms])
7fffc007d1f5 virtnet_poll ([kernel.kallsyms])
7fffb343c07f net_rx_action ([kernel.kallsyms])
7fffb2ea2f05 __do_softirq ([kernel.kallsyms])
7fffb357a32c call_softirq ([kernel.kallsyms])
7fffb2e30675 do_softirq ([kernel.kallsyms])
7fffb2ea3285 irq_exit ([kernel.kallsyms])
7fffb357b5e6 __irqentry_text_start ([kernel.kallsyms])
7fffb356d362 ret_from_intr ([kernel.kallsyms])
7fffb356c12e default_idle ([kernel.kallsyms])
7fffb2e386f0 arch_cpu_idle ([kernel.kallsyms])
7fffb2efe3ba cpu_startup_entry ([kernel.kallsyms])
7fffb2e59db7 start_secondary ([kernel.kallsyms])
7fffb2e020d5 start_cpu ([kernel.kallsyms])
swapper 0 [001] 69006.754090: skb:consume_skb: skbaddr=0xffff917db9647100
7fffb3425a00 consume_skb ([kernel.kallsyms])
7fffb34ba3cb arp_process ([kernel.kallsyms])
7fffb34bad65 arp_rcv ([kernel.kallsyms])
7fffb343b6d9 __netif_receive_skb_core ([kernel.kallsyms])
7fffb343b9d8 __netif_receive_skb ([kernel.kallsyms])
7fffb343ba60 netif_receive_skb_internal ([kernel.kallsyms])
7fffb343c6e8 napi_gro_receive ([kernel.kallsyms])
7fffc007d1f5 virtnet_poll ([kernel.kallsyms])
7fffb343c07f net_rx_action ([kernel.kallsyms])
7fffb2ea2f05 __do_softirq ([kernel.kallsyms])
7fffb357a32c call_softirq ([kernel.kallsyms])
7fffb2e30675 do_softirq ([kernel.kallsyms])
7fffb2ea3285 irq_exit ([kernel.kallsyms])
7fffb357b5e6 __irqentry_text_start ([kernel.kallsyms])
7fffb356d362 ret_from_intr ([kernel.kallsyms])
7fffb356c12e default_idle ([kernel.kallsyms])
7fffb2e386f0 arch_cpu_idle ([kernel.kallsyms])
7fffb2efe3ba cpu_startup_entry ([kernel.kallsyms])
any idea why I could get a proper call trace on the new kernel?
Thanks.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: perf script doesn't dump a normal call trace
2018-11-02 6:36 perf script doesn't dump a normal call trace Xin Long
@ 2018-11-02 10:26 ` Jiri Olsa
2018-11-03 9:36 ` Xin Long
0 siblings, 1 reply; 7+ messages in thread
From: Jiri Olsa @ 2018-11-02 10:26 UTC (permalink / raw)
To: Xin Long
Cc: LKML, linux-perf-users, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Namhyung Kim
On Fri, Nov 02, 2018 at 03:36:13PM +0900, Xin Long wrote:
> On upstream kernel(4.19) or RHEL-8 kernel(4.18.0):
>
> # perf record -e 'skb:consume_skb' -ag
> ^C[ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.612 MB perf.data (634 samples) ]
>
> # perf script
> swapper 0 [009] 274370.117711: skb:consume_skb: skbaddr=0xffff962c591d5b00
> ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
>
> kworker/9:1-eve 926 [009] 274370.117729: skb:consume_skb:
> skbaddr=0xffff962c591d5b00
> ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
>
> kworker/9:1-eve 926 [009] 274370.117732: skb:consume_skb:
> skbaddr=0xffff962c591d4900
> ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
>
> swapper 0 [009] 274370.145528: skb:consume_skb: skbaddr=0xffff962c591d4900
> ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
>
> kworker/9:1-eve 926 [009] 274370.145545: skb:consume_skb:
> skbaddr=0xffff962c591d4900
> ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
>
> kworker/9:1-eve 926 [009] 274370.145547: skb:consume_skb:
> skbaddr=0xffff962c591d5b00
> ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
>
> swapper 0 [009] 274370.173443: skb:consume_skb: skbaddr=0xffff962c591d5b00
> ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
I can see that on upstream as well, probably something within
tracepoint entry code, because I have it working nicely when
from kprobe, like:
[root@ibm-x3650m4-02 perf]# ./perf probe 'consume_skb'
[root@ibm-x3650m4-02 perf]# ./perf record -g -e probe:consume_skb* -aR ^C
jirka
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: perf script doesn't dump a normal call trace
2018-11-02 10:26 ` Jiri Olsa
@ 2018-11-03 9:36 ` Xin Long
2018-11-04 19:17 ` Jiri Olsa
0 siblings, 1 reply; 7+ messages in thread
From: Xin Long @ 2018-11-03 9:36 UTC (permalink / raw)
To: Jiri Olsa
Cc: LKML, linux-perf-users, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Namhyung Kim
On Fri, Nov 2, 2018 at 7:26 PM Jiri Olsa <jolsa@redhat.com> wrote:
>
> On Fri, Nov 02, 2018 at 03:36:13PM +0900, Xin Long wrote:
> > On upstream kernel(4.19) or RHEL-8 kernel(4.18.0):
> >
> > # perf record -e 'skb:consume_skb' -ag
> > ^C[ perf record: Woken up 1 times to write data ]
> > [ perf record: Captured and wrote 0.612 MB perf.data (634 samples) ]
> >
> > # perf script
> > swapper 0 [009] 274370.117711: skb:consume_skb: skbaddr=0xffff962c591d5b00
> > ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
> >
> > kworker/9:1-eve 926 [009] 274370.117729: skb:consume_skb:
> > skbaddr=0xffff962c591d5b00
> > ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
> >
> > kworker/9:1-eve 926 [009] 274370.117732: skb:consume_skb:
> > skbaddr=0xffff962c591d4900
> > ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
> >
> > swapper 0 [009] 274370.145528: skb:consume_skb: skbaddr=0xffff962c591d4900
> > ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
> >
> > kworker/9:1-eve 926 [009] 274370.145545: skb:consume_skb:
> > skbaddr=0xffff962c591d4900
> > ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
> >
> > kworker/9:1-eve 926 [009] 274370.145547: skb:consume_skb:
> > skbaddr=0xffff962c591d5b00
> > ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
> >
> > swapper 0 [009] 274370.173443: skb:consume_skb: skbaddr=0xffff962c591d5b00
> > ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
>
> I can see that on upstream as well, probably something within
> tracepoint entry code, because I have it working nicely when
> from kprobe, like:
>
> [root@ibm-x3650m4-02 perf]# ./perf probe 'consume_skb'
> [root@ibm-x3650m4-02 perf]# ./perf record -g -e probe:consume_skb* -aR ^C
>
Thanks Jiri,
My debugging script is using tracepoint with some filters which I
don't think probe can support.
Any one have fixes for this tracepoint issue?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: perf script doesn't dump a normal call trace
2018-11-03 9:36 ` Xin Long
@ 2018-11-04 19:17 ` Jiri Olsa
2018-11-05 6:20 ` Xin Long
0 siblings, 1 reply; 7+ messages in thread
From: Jiri Olsa @ 2018-11-04 19:17 UTC (permalink / raw)
To: Xin Long
Cc: LKML, linux-perf-users, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Namhyung Kim
On Sat, Nov 03, 2018 at 06:36:21PM +0900, Xin Long wrote:
> On Fri, Nov 2, 2018 at 7:26 PM Jiri Olsa <jolsa@redhat.com> wrote:
> >
> > On Fri, Nov 02, 2018 at 03:36:13PM +0900, Xin Long wrote:
> > > On upstream kernel(4.19) or RHEL-8 kernel(4.18.0):
> > >
> > > # perf record -e 'skb:consume_skb' -ag
> > > ^C[ perf record: Woken up 1 times to write data ]
> > > [ perf record: Captured and wrote 0.612 MB perf.data (634 samples) ]
> > >
> > > # perf script
> > > swapper 0 [009] 274370.117711: skb:consume_skb: skbaddr=0xffff962c591d5b00
> > > ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
> > >
> > > kworker/9:1-eve 926 [009] 274370.117729: skb:consume_skb:
> > > skbaddr=0xffff962c591d5b00
> > > ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
> > >
> > > kworker/9:1-eve 926 [009] 274370.117732: skb:consume_skb:
> > > skbaddr=0xffff962c591d4900
> > > ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
> > >
> > > swapper 0 [009] 274370.145528: skb:consume_skb: skbaddr=0xffff962c591d4900
> > > ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
> > >
> > > kworker/9:1-eve 926 [009] 274370.145545: skb:consume_skb:
> > > skbaddr=0xffff962c591d4900
> > > ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
> > >
> > > kworker/9:1-eve 926 [009] 274370.145547: skb:consume_skb:
> > > skbaddr=0xffff962c591d5b00
> > > ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
> > >
> > > swapper 0 [009] 274370.173443: skb:consume_skb: skbaddr=0xffff962c591d5b00
> > > ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
> >
> > I can see that on upstream as well, probably something within
> > tracepoint entry code, because I have it working nicely when
> > from kprobe, like:
> >
> > [root@ibm-x3650m4-02 perf]# ./perf probe 'consume_skb'
> > [root@ibm-x3650m4-02 perf]# ./perf record -g -e probe:consume_skb* -aR ^C
> >
> Thanks Jiri,
>
> My debugging script is using tracepoint with some filters which I
> don't think probe can support.
> Any one have fixes for this tracepoint issue?
trying to bisect that.. looks like orc code issue,
it works for me when you switch to fp unwind:
CONFIG_UNWINDER_FRAME_POINTER
jirka
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: perf script doesn't dump a normal call trace
2018-11-04 19:17 ` Jiri Olsa
@ 2018-11-05 6:20 ` Xin Long
2018-11-05 8:49 ` Jiri Olsa
0 siblings, 1 reply; 7+ messages in thread
From: Xin Long @ 2018-11-05 6:20 UTC (permalink / raw)
To: Jiri Olsa
Cc: LKML, linux-perf-users, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Namhyung Kim
On Mon, Nov 5, 2018 at 4:18 AM Jiri Olsa <jolsa@redhat.com> wrote:
>
> On Sat, Nov 03, 2018 at 06:36:21PM +0900, Xin Long wrote:
> > On Fri, Nov 2, 2018 at 7:26 PM Jiri Olsa <jolsa@redhat.com> wrote:
> > >
> > > On Fri, Nov 02, 2018 at 03:36:13PM +0900, Xin Long wrote:
> > > > On upstream kernel(4.19) or RHEL-8 kernel(4.18.0):
> > > >
> > > > # perf record -e 'skb:consume_skb' -ag
> > > > ^C[ perf record: Woken up 1 times to write data ]
> > > > [ perf record: Captured and wrote 0.612 MB perf.data (634 samples) ]
> > > >
> > > > # perf script
> > > > swapper 0 [009] 274370.117711: skb:consume_skb: skbaddr=0xffff962c591d5b00
> > > > ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
> > > >
> > > > kworker/9:1-eve 926 [009] 274370.117729: skb:consume_skb:
> > > > skbaddr=0xffff962c591d5b00
> > > > ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
> > > >
> > > > kworker/9:1-eve 926 [009] 274370.117732: skb:consume_skb:
> > > > skbaddr=0xffff962c591d4900
> > > > ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
> > > >
> > > > swapper 0 [009] 274370.145528: skb:consume_skb: skbaddr=0xffff962c591d4900
> > > > ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
> > > >
> > > > kworker/9:1-eve 926 [009] 274370.145545: skb:consume_skb:
> > > > skbaddr=0xffff962c591d4900
> > > > ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
> > > >
> > > > kworker/9:1-eve 926 [009] 274370.145547: skb:consume_skb:
> > > > skbaddr=0xffff962c591d5b00
> > > > ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
> > > >
> > > > swapper 0 [009] 274370.173443: skb:consume_skb: skbaddr=0xffff962c591d5b00
> > > > ffffffffa4abe534 consume_skb+0x64 ([kernel.kallsyms])
> > >
> > > I can see that on upstream as well, probably something within
> > > tracepoint entry code, because I have it working nicely when
> > > from kprobe, like:
> > >
> > > [root@ibm-x3650m4-02 perf]# ./perf probe 'consume_skb'
> > > [root@ibm-x3650m4-02 perf]# ./perf record -g -e probe:consume_skb* -aR ^C
> > >
> > Thanks Jiri,
> >
> > My debugging script is using tracepoint with some filters which I
> > don't think probe can support.
> > Any one have fixes for this tracepoint issue?
>
> trying to bisect that.. looks like orc code issue,
> it works for me when you switch to fp unwind:
> CONFIG_UNWINDER_FRAME_POINTER
>
That's a good workaround, thanks.
Another problem is when I'm using perf built manually from upstream kernel tree,
I couldn't see the function's names.
# perf --version
perf version 4.19.g26f1de
# perf report -T
# To display the perf.data header info, please use
--header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 97 of event 'probe:consume_skb'
# Event count (approx.): 97
#
# Children Self Trace output
# ........ ........ ..................
#
100.00% 100.00% (ffffffff86f090f0)
|
|--93.81%--0xffffffff868000e6
| 0xffffffff8684ed7f
| 0xffffffff868e97ad
| 0xffffffff868e953a
| 0xffffffff87087623
| 0xffffffff8682a06f
| 0xffffffff870872ad
| |
| |--89.69%--0xffffffff8720098f
| | 0xffffffff87201b69
| | 0xffffffff868b9c2e
The below is with rhel7's perf
# perf --version
perf version 3.10.0-957.el7.x86_64.debug
# perf report -T
# To display the perf.data header info, please use
--header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 97 of event 'probe:consume_skb'
# Event count (approx.): 97
#
# Children Self Trace output
# ........ ........ ..................
#
100.00% 100.00% (ffffffff86f090f0)
|
|--93.81%--0x2000e6
| start_secondary
| cpu_startup_entry
| do_idle
| default_idle_call
| arch_cpu_idle
| default_idle
| |
| |--89.69%--ret_from_intr
| | do_IRQ
| | irq_exit
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: perf script doesn't dump a normal call trace
2018-11-05 6:20 ` Xin Long
@ 2018-11-05 8:49 ` Jiri Olsa
2018-11-06 8:22 ` Xin Long
0 siblings, 1 reply; 7+ messages in thread
From: Jiri Olsa @ 2018-11-05 8:49 UTC (permalink / raw)
To: Xin Long
Cc: LKML, linux-perf-users, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Namhyung Kim
On Mon, Nov 05, 2018 at 03:20:15PM +0900, Xin Long wrote:
SNIP
> > > > [root@ibm-x3650m4-02 perf]# ./perf probe 'consume_skb'
> > > > [root@ibm-x3650m4-02 perf]# ./perf record -g -e probe:consume_skb* -aR ^C
> > > >
> > > Thanks Jiri,
> > >
> > > My debugging script is using tracepoint with some filters which I
> > > don't think probe can support.
> > > Any one have fixes for this tracepoint issue?
> >
> > trying to bisect that.. looks like orc code issue,
> > it works for me when you switch to fp unwind:
> > CONFIG_UNWINDER_FRAME_POINTER
> >
>
> That's a good workaround, thanks.
>
> Another problem is when I'm using perf built manually from upstream kernel tree,
> I couldn't see the function's names.
> # perf --version
> perf version 4.19.g26f1de
>
> # perf report -T
> # To display the perf.data header info, please use
> --header/--header-only options.
> #
> #
> # Total Lost Samples: 0
> #
> # Samples: 97 of event 'probe:consume_skb'
> # Event count (approx.): 97
> #
> # Children Self Trace output
> # ........ ........ ..................
> #
> 100.00% 100.00% (ffffffff86f090f0)
> |
> |--93.81%--0xffffffff868000e6
> | 0xffffffff8684ed7f
> | 0xffffffff868e97ad
> | 0xffffffff868e953a
> | 0xffffffff87087623
> | 0xffffffff8682a06f
> | 0xffffffff870872ad
> | |
> | |--89.69%--0xffffffff8720098f
> | | 0xffffffff87201b69
> | | 0xffffffff868b9c2e
>
>
> The below is with rhel7's perf
> # perf --version
> perf version 3.10.0-957.el7.x86_64.debug
> # perf report -T
> # To display the perf.data header info, please use
> --header/--header-only options.
> #
> #
> # Total Lost Samples: 0
> #
> # Samples: 97 of event 'probe:consume_skb'
> # Event count (approx.): 97
> #
> # Children Self Trace output
> # ........ ........ ..................
> #
> 100.00% 100.00% (ffffffff86f090f0)
> |
> |--93.81%--0x2000e6
> | start_secondary
> | cpu_startup_entry
> | do_idle
> | default_idle_call
> | arch_cpu_idle
> | default_idle
> | |
> | |--89.69%--ret_from_intr
> | | do_IRQ
> | | irq_exit
I think that's already fixed on Arnaldo's perf/urgent branch,
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
but perhaps this post as well:
https://lore.kernel.org/lkml/20181031091043.23465-1-adrian.hunter@intel.com/
please give it a try.. it should be merged in soon
jirka
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: perf script doesn't dump a normal call trace
2018-11-05 8:49 ` Jiri Olsa
@ 2018-11-06 8:22 ` Xin Long
0 siblings, 0 replies; 7+ messages in thread
From: Xin Long @ 2018-11-06 8:22 UTC (permalink / raw)
To: Jiri Olsa
Cc: LKML, linux-perf-users, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Namhyung Kim
On Mon, Nov 5, 2018 at 5:49 PM Jiri Olsa <jolsa@redhat.com> wrote:
>
> On Mon, Nov 05, 2018 at 03:20:15PM +0900, Xin Long wrote:
>
> SNIP
>
> > > > > [root@ibm-x3650m4-02 perf]# ./perf probe 'consume_skb'
> > > > > [root@ibm-x3650m4-02 perf]# ./perf record -g -e probe:consume_skb* -aR ^C
> > > > >
> > > > Thanks Jiri,
> > > >
> > > > My debugging script is using tracepoint with some filters which I
> > > > don't think probe can support.
> > > > Any one have fixes for this tracepoint issue?
> > >
> > > trying to bisect that.. looks like orc code issue,
> > > it works for me when you switch to fp unwind:
> > > CONFIG_UNWINDER_FRAME_POINTER
> > >
> >
> > That's a good workaround, thanks.
> >
> > Another problem is when I'm using perf built manually from upstream kernel tree,
> > I couldn't see the function's names.
> > # perf --version
> > perf version 4.19.g26f1de
> >
> > # perf report -T
> > # To display the perf.data header info, please use
> > --header/--header-only options.
> > #
> > #
> > # Total Lost Samples: 0
> > #
> > # Samples: 97 of event 'probe:consume_skb'
> > # Event count (approx.): 97
> > #
> > # Children Self Trace output
> > # ........ ........ ..................
> > #
> > 100.00% 100.00% (ffffffff86f090f0)
> > |
> > |--93.81%--0xffffffff868000e6
> > | 0xffffffff8684ed7f
> > | 0xffffffff868e97ad
> > | 0xffffffff868e953a
> > | 0xffffffff87087623
> > | 0xffffffff8682a06f
> > | 0xffffffff870872ad
> > | |
> > | |--89.69%--0xffffffff8720098f
> > | | 0xffffffff87201b69
> > | | 0xffffffff868b9c2e
> >
> >
> > The below is with rhel7's perf
> > # perf --version
> > perf version 3.10.0-957.el7.x86_64.debug
> > # perf report -T
> > # To display the perf.data header info, please use
> > --header/--header-only options.
> > #
> > #
> > # Total Lost Samples: 0
> > #
> > # Samples: 97 of event 'probe:consume_skb'
> > # Event count (approx.): 97
> > #
> > # Children Self Trace output
> > # ........ ........ ..................
> > #
> > 100.00% 100.00% (ffffffff86f090f0)
> > |
> > |--93.81%--0x2000e6
> > | start_secondary
> > | cpu_startup_entry
> > | do_idle
> > | default_idle_call
> > | arch_cpu_idle
> > | default_idle
> > | |
> > | |--89.69%--ret_from_intr
> > | | do_IRQ
> > | | irq_exit
>
> I think that's already fixed on Arnaldo's perf/urgent branch,
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
>
> but perhaps this post as well:
> https://lore.kernel.org/lkml/20181031091043.23465-1-adrian.hunter@intel.com/
>
> please give it a try.. it should be merged in soon
I will try it later, I have another question?
# perf report -T
# Samples: 97 of event 'probe:consume_skb'
# Event count (approx.): 97
#
# Children Self Trace output
# ........ ........ ..................
#
100.00% 100.00% (ffffffff86f090f0)
|
|--93.81%--0x2000e6
| start_secondary
| cpu_startup_entry
| do_idle
| default_idle_call
| arch_cpu_idle
[...]
| | |
| | --2.06%--arp_process
| | neigh_update
| | __neigh_notify
| | rtnl_notify
| | nlmsg_notify
| | consume_skb <-----[1]
This command can show a nice tree, and it has the total samples number 97.
But I couldn't see how many of them are from [1]?
Do you know how to count each path's numbers?
Is there an option for "perf report" to do these statistics?
Thanks.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-11-06 8:22 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-02 6:36 perf script doesn't dump a normal call trace Xin Long
2018-11-02 10:26 ` Jiri Olsa
2018-11-03 9:36 ` Xin Long
2018-11-04 19:17 ` Jiri Olsa
2018-11-05 6:20 ` Xin Long
2018-11-05 8:49 ` Jiri Olsa
2018-11-06 8:22 ` Xin Long
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).