From: Ravi Bangoria <ravi.bangoria@amd.com>
To: <acme@kernel.org>
Cc: <ravi.bangoria@amd.com>, <jolsa@kernel.org>,
<namhyung@kernel.org>, <irogers@google.com>,
<kan.liang@linux.intel.com>, <peterz@infradead.org>,
<mark.rutland@arm.com>, <mingo@redhat.com>,
<alexander.shishkin@linux.intel.com>, <james.clark@arm.com>,
<german.gomez@arm.com>, <leo.yan@linaro.org>,
<adrian.hunter@intel.com>, <alexey.v.bayduraev@linux.intel.com>,
<linux-perf-users@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <sandipan.das@amd.com>,
<ananth.narayan@amd.com>, <santosh.shukla@amd.com>
Subject: [RFC 0/4] perf tool: Fix non-".text" symbol resolution for kernel modules
Date: Tue, 10 Jan 2023 11:28:55 +0530 [thread overview]
Message-ID: <20230110055859.685-1-ravi.bangoria@amd.com> (raw)
Kernel module elf contains executable code in non-".text" sections as
well, for ex: ".noinstr.text". Plus, kernel module's memory layout
differs from it's binary layout because .ko elf does not contain
program header table.
Perf tries to solve it by creating special maps for allocated (SHF_ALLOC)
elf sections, but perf uses elf addresses for map address range and thus
these special maps remains unused because no real ip falls into their
address range.
Solve this by preparing section specific special maps using addresses
provided by sysfs /sys/module/.../sections/. Also save these details in
PERF_RECORD_KMOD_SEC_MAP format in perf.data which can be consumed at
perf-report time.
Without patchset:
# perf record -a -c 5000000
# perf report
Overhead Command Shared Object Symbol
13.20% qemu-system-x86 [unknown] [.] 0x00005557527b1973
6.58% qemu-system-x86 [kvm_amd] [k] 0x00000000000151e6
6.36% qemu-system-x86 [kernel.vmlinux] [k] native_load_gdt
6.21% qemu-system-x86 [kernel.vmlinux] [k] native_load_tr_desc
4.71% qemu-system-x86 [kvm] [k] vcpu_run
4.52% qemu-system-x86 [kvm_amd] [k] svm_vcpu_run
3.50% qemu-system-x86 [kvm] [k] kvm_cpuid
2.09% qemu-system-x86 [kvm] [k] kvm_pmu_trigger_event
1.98% qemu-system-x86 [kvm_amd] [k] 0x0000000000015171
1.05% qemu-system-x86 [kvm_amd] [k] svm_handle_exit
1.04% qemu-system-x86 [kvm_amd] [k] 0x00000000000151e2
0.94% qemu-system-x86 [kvm_amd] [k] 0x0000000000015174
Same perf.data with kallsyms:
# perf report --kallsyms=/proc/kallsyms
Overhead Command Shared Object Symbol
14.22% qemu-system-x86 [kvm_amd] [k] __svm_vcpu_run
13.20% qemu-system-x86 [unknown] [.] 0x00005557527b1973
6.36% qemu-system-x86 [kernel.vmlinux] [k] native_load_gdt
6.21% qemu-system-x86 [kernel.vmlinux] [k] native_load_tr_desc
4.71% qemu-system-x86 [kvm] [k] vcpu_run
4.52% qemu-system-x86 [kvm_amd] [k] svm_vcpu_run
3.50% qemu-system-x86 [kvm] [k] kvm_cpuid
2.09% qemu-system-x86 [kvm] [k] kvm_pmu_trigger_event
1.05% qemu-system-x86 [kvm_amd] [k] svm_handle_exit
With patchset:
# perf record -a -c 5000000
# perf report
Overhead Command Shared Object Symbol
13.44% qemu-system-x86 [kvm-amd].noinstr.text [k] __svm_vcpu_run
13.25% qemu-system-x86 [unknown] [.] 0x000055f4c6563973
7.13% qemu-system-x86 [kernel.vmlinux] [k] native_load_gdt
6.00% qemu-system-x86 [kernel.vmlinux] [k] native_load_tr_desc
5.13% qemu-system-x86 [kvm_amd] [k] svm_vcpu_run
4.83% qemu-system-x86 [kvm] [k] vcpu_run
3.65% qemu-system-x86 [kvm] [k] kvm_cpuid
Same perf.data with kallsyms:
# perf report --kallsyms=/proc/kallsyms
Overhead Command Shared Object Symbol
13.44% qemu-system-x86 [kernel.vmlinux] [k] __svm_vcpu_run
13.25% qemu-system-x86 [unknown] [.] 0x000055f4c6563973
7.13% qemu-system-x86 [kernel.vmlinux] [k] native_load_gdt
6.00% qemu-system-x86 [kernel.vmlinux] [k] native_load_tr_desc
5.13% qemu-system-x86 [kernel.vmlinux] [k] svm_vcpu_run
4.83% qemu-system-x86 [kernel.vmlinux] [k] vcpu_run
3.65% qemu-system-x86 [kernel.vmlinux] [k] kvm_cpuid
This is an RFC only series. TODOs:
- I'm just recording module path in PERF_RECORD_KMOD_SEC_MAP. It's very
much possible that, at perf report time, a module file exists at the
same path but it's internal layout is different. I think I need to add
some buildid check. Any ideas?
- I've enabled host perf-record/report only. It doesn't work for guest
modules because host does not have access to guest sysfs. I'm yet to
figure out how to fix it. May be we can add --guest-mod-sysfs option.
Any ideas?
- Also, I'm currently assuming that module files are not compressed.
- I've seen perf build failures when compiling with NO_LIBELF=1.
- I've seen perf report not honoring --kallsyms in certain conditions.
Prepared on top of acme/perf/core (69b41ac87e4a6)
Ravi Bangoria (4):
perf tool: Simplify machine__create_modules() a bit
perf tool: Refactor perf_event__synthesize_modules()
perf tool: Introduce PERF_RECORD_KMOD_SEC_MAP
perf tool: Fix non-".text" symbol resolution for kernel modules
tools/lib/perf/Documentation/libperf.txt | 1 +
tools/lib/perf/include/perf/event.h | 25 +++
tools/perf/builtin-annotate.c | 1 +
tools/perf/builtin-c2c.c | 1 +
tools/perf/builtin-diff.c | 1 +
tools/perf/builtin-inject.c | 1 +
tools/perf/builtin-kmem.c | 1 +
tools/perf/builtin-mem.c | 1 +
tools/perf/builtin-record.c | 14 ++
tools/perf/builtin-report.c | 1 +
tools/perf/builtin-script.c | 13 ++
tools/perf/builtin-trace.c | 1 +
tools/perf/util/build-id.c | 1 +
tools/perf/util/data-convert-bt.c | 1 +
tools/perf/util/data-convert-json.c | 1 +
tools/perf/util/event.c | 22 ++
tools/perf/util/event.h | 5 +
tools/perf/util/machine.c | 268 ++++++++++++++++++++++-
tools/perf/util/machine.h | 2 +
tools/perf/util/map.c | 1 +
tools/perf/util/map.h | 4 +
tools/perf/util/session.c | 17 ++
tools/perf/util/symbol-elf.c | 9 +-
tools/perf/util/symbol.c | 2 +-
tools/perf/util/synthetic-events.c | 136 +++++++++---
tools/perf/util/tool.h | 3 +-
26 files changed, 494 insertions(+), 39 deletions(-)
--
2.39.0
next reply other threads:[~2023-01-10 6:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-10 5:58 Ravi Bangoria [this message]
2023-01-10 5:58 ` [RFC 1/4] perf tool: Simplify machine__create_modules() a bit Ravi Bangoria
2023-01-10 5:58 ` [RFC 2/4] perf tool: Refactor perf_event__synthesize_modules() Ravi Bangoria
2023-01-10 5:58 ` [RFC 3/4] perf tool: Introduce PERF_RECORD_KMOD_SEC_MAP Ravi Bangoria
2023-01-16 6:14 ` Adrian Hunter
2023-01-16 13:34 ` Ravi Bangoria
2023-01-10 5:58 ` [RFC 4/4] perf tool: Fix non-".text" symbol resolution for kernel modules Ravi Bangoria
2023-02-07 7:35 ` kernel test robot
2023-01-10 6:35 ` [RFC 0/4] " Adrian Hunter
2023-01-10 8:43 ` Ravi Bangoria
2023-01-10 8:58 ` Ravi Bangoria
2023-01-16 4:21 ` Ravi Bangoria
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230110055859.685-1-ravi.bangoria@amd.com \
--to=ravi.bangoria@amd.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=alexey.v.bayduraev@linux.intel.com \
--cc=ananth.narayan@amd.com \
--cc=german.gomez@arm.com \
--cc=irogers@google.com \
--cc=james.clark@arm.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=leo.yan@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=sandipan.das@amd.com \
--cc=santosh.shukla@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®