From: Adrian Hunter <adrian.hunter@intel.com>
To: Ravi Bangoria <ravi.bangoria@amd.com>, acme@kernel.org
Cc: 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,
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: Re: [RFC 0/4] perf tool: Fix non-".text" symbol resolution for kernel modules
Date: Tue, 10 Jan 2023 08:35:48 +0200 [thread overview]
Message-ID: <86f43058-a51a-42c7-4d75-564f0e8eef04@intel.com> (raw)
In-Reply-To: <20230110055859.685-1-ravi.bangoria@amd.com>
On 10/01/23 07:58, Ravi Bangoria wrote:
> 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.
Have you looked at using perf record --kcore option.
>
> 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(-)
>
next prev parent reply other threads:[~2023-01-10 6:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-10 5:58 Ravi Bangoria
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 ` Adrian Hunter [this message]
2023-01-10 8:43 ` [RFC 0/4] " 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=86f43058-a51a-42c7-4d75-564f0e8eef04@intel.com \
--to=adrian.hunter@intel.com \
--cc=acme@kernel.org \
--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=ravi.bangoria@amd.com \
--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®