Re: Perf Reports Jump Instructions as Memory Access Instructions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: Perf Reports Jump Instructions as Memory Access Instructions
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
- Date: Tue, 26 May 2020 09:42:00 -0700
- Cc: Steven Rostedt <rostedt@xxxxxxxxxxx>, Andi Kleen <andi@xxxxxxxxxxxxxx>, Jin Yao <yao.jin@xxxxxxxxxxxxxxx>, ahmadkhorrami <ahmadkhorrami@xxxxxxxx>, Linux-trace Users <linux-trace-users@xxxxxxxxxxxxxxx>, linux-perf-users@xxxxxxxxxxxxxxx, Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>
- In-reply-to: <20200526133817.GA23187@redhat.com>
- References: <20200526133817.GA23187@redhat.com>
- User-agent: NeoMutt/20170113 (1.7.2)
> > > The access point is at offset 0 of the following disassembly:
> > Dump of assembler code for function cairo_surface_get_device_scale@plt:
> > > 0x000000000002a310 <+0>: jmpq *0x2c8b3a(%rip) # 0x2f2e50
> > > 0x000000000002a316 <+6>: pushq $0x1c7
> > > 0x000000000002a31b <+11>: jmpq 0x28690
> > >
> > > This is an unconditional jump which will not lead to macrofusion.
>
> But that will access memory, no? The instruction at offset 0.
Instruction fetches are not sampled by the MEM_INST_RETIRED event.
This is an indirect jump through memory, so it accesses the memory at
0x2c8b3a(%rip). These kind of accesses are sampled by the event.
Other memory accesses as part of other instructions may be sampled too.
-Andi
[Index of Archives]
[Linux USB Development]
[Linux USB Development]
[Linux Audio Users]
[Yosemite Hiking]
[Linux Kernel]
[Linux SCSI]