From: Namhyung Kim <namhyung@kernel.org>
To: Ian Rogers <irogers@google.com>
Cc: "Peter Zijlstra" <peterz@infradead.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Arnaldo Carvalho de Melo" <acme@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
"Jiri Olsa" <jolsa@kernel.org>,
"Adrian Hunter" <adrian.hunter@intel.com>,
"Kan Liang" <kan.liang@linux.intel.com>,
"John Garry" <john.g.garry@oracle.com>,
"Will Deacon" <will@kernel.org>,
"James Clark" <james.clark@linaro.org>,
"Mike Leach" <mike.leach@linaro.org>,
"Leo Yan" <leo.yan@linux.dev>,
"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
"Ravi Bangoria" <ravi.bangoria@amd.com>,
"Charlie Jenkins" <charlie@rivosinc.com>,
"Colin Ian King" <colin.i.king@gmail.com>,
"Andi Kleen" <ak@linux.intel.com>,
"Dmitry Vyukov" <dvyukov@google.com>,
"Graham Woodward" <graham.woodward@arm.com>,
"Ilkka Koskinen" <ilkka@os.amperecomputing.com>,
"Zhongqiu Han" <quic_zhonhan@quicinc.com>,
"Yicong Yang" <yangyicong@hisilicon.com>,
"Athira Rajeev" <atrajeev@linux.ibm.com>,
"Kajol Jain" <kjain@linux.ibm.com>,
"Li Huafei" <lihuafei1@huawei.com>,
"Steinar H. Gunderson" <sesse@google.com>,
"Stephen Brennan" <stephen.s.brennan@oracle.com>,
"Chun-Tse Shao" <ctshao@google.com>,
"Yujie Liu" <yujie.liu@intel.com>,
"Dr. David Alan Gilbert" <linux@treblig.org>,
"Levi Yun" <yeoreum.yun@arm.com>,
"Howard Chu" <howardchu95@gmail.com>,
"Weilin Wang" <weilin.wang@intel.com>,
"Thomas Falcon" <thomas.falcon@intel.com>,
"Matt Fleming" <matt@readmodwrite.com>,
"Veronika Molnarova" <vmolnaro@redhat.com>,
"Krzysztof Łopatowski" <krzysztof.m.lopatowski@gmail.com>,
"Zixian Cai" <fzczx123@gmail.com>,
"Steve Clevenger" <scclevenger@os.amperecomputing.com>,
"Ben Gainey" <ben.gainey@arm.com>,
"Chaitanya S Prakash" <chaitanyas.prakash@arm.com>,
"Martin Liska" <martin.liska@hey.com>,
"Martin Liška" <m.liska@foxlink.cz>, "Song Liu" <song@kernel.org>,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 08/23] perf record: Make --buildid-mmap the default
Date: Mon, 30 Jun 2025 22:43:36 -0700 [thread overview]
Message-ID: <aGN1iPzoeNVxW5fQ@google.com> (raw)
In-Reply-To: <20250628045017.1361563-9-irogers@google.com>
On Fri, Jun 27, 2025 at 09:50:02PM -0700, Ian Rogers wrote:
> Support for build IDs in mmap2 perf events has been present since
> Linux v5.12:
> https://lore.kernel.org/lkml/20210219194619.1780437-1-acme@kernel.org/
> Build ID mmap events don't avoid the need to inject build IDs for DSO
> touched by samples as the build ID cache is populated by perf
> record. They can avoid some cases of symbol mis-resolution caused by
> the file system changing from when a sample occurred and when the DSO
> is sought. To disable build ID scanning
>
> Unlike the --buildid-mmap option, this doesn't disable the build ID
> cache but it does disable the processing of samples looking for DSOs
> to inject build IDs for. To disable the build ID cache the -B
> (--no-buildid) option should be used.
I think we need to add a config option to control this behavior later.
Let me think about this more.
>
> Making this option the default was raised on the list in:
> https://lore.kernel.org/linux-perf-users/CAP-5=fXP7jN_QrGUcd55_QH5J-Y-FCaJ6=NaHVtyx0oyNh8_-Q@mail.gmail.com/
>
> Signed-off-by: Ian Rogers <irogers@google.com>
> ---
> tools/perf/builtin-record.c | 33 +++++++++++++++++++-----------
> tools/perf/util/symbol_conf.h | 2 +-
> tools/perf/util/synthetic-events.c | 16 +++++++--------
> 3 files changed, 30 insertions(+), 21 deletions(-)
>
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index 53971b9de3ba..29428fb8ac67 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -171,6 +171,7 @@ struct record {
> bool no_buildid_cache_set;
> bool buildid_all;
> bool buildid_mmap;
> + bool buildid_mmap_set;
> bool timestamp_filename;
> bool timestamp_boundary;
> bool off_cpu;
> @@ -1811,6 +1812,7 @@ record__finish_output(struct record *rec)
> data->dir.files[i].size = lseek(data->dir.files[i].fd, 0, SEEK_CUR);
> }
>
> + /* Buildid scanning disabled or build ID in kernel and synthesized map events. */
> if (!rec->no_buildid) {
> process_buildids(rec);
>
> @@ -3005,6 +3007,8 @@ static int perf_record_config(const char *var, const char *value, void *cb)
> rec->no_buildid = true;
> else if (!strcmp(value, "mmap"))
> rec->buildid_mmap = true;
> + else if (!strcmp(value, "no-mmap"))
> + rec->buildid_mmap = false;
> else
> return -1;
> return 0;
> @@ -3411,6 +3415,7 @@ static struct record record = {
> .synth = PERF_SYNTH_ALL,
> .off_cpu_thresh_ns = OFFCPU_THRESH,
> },
> + .buildid_mmap = true,
> };
>
> const char record_callchain_help[] = CALLCHAIN_RECORD_HELP
> @@ -3577,8 +3582,8 @@ static struct option __record_options[] = {
> "file", "vmlinux pathname"),
> OPT_BOOLEAN(0, "buildid-all", &record.buildid_all,
> "Record build-id of all DSOs regardless of hits"),
> - OPT_BOOLEAN(0, "buildid-mmap", &record.buildid_mmap,
> - "Record build-id in map events"),
> + OPT_BOOLEAN_SET(0, "buildid-mmap", &record.buildid_mmap, &record.buildid_mmap_set,
> + "Legacy record build-id in map events option which is now the default. Behaves indentically to --no-buildid. Disable with --no-buildid-mmap"),
Looks too long. Maybe just like below:
"Record build-id in mmap events and skip build-id processing."
The detailed explanation can go to the documentation.
> OPT_BOOLEAN(0, "timestamp-filename", &record.timestamp_filename,
> "append timestamp to output filename"),
> OPT_BOOLEAN(0, "timestamp-boundary", &record.timestamp_boundary,
> @@ -4108,19 +4113,23 @@ int cmd_record(int argc, const char **argv)
> record.opts.record_switch_events = true;
> }
>
> + if (!rec->buildid_mmap) {
> + pr_debug("Disabling build id in synthesized mmap2 events.\n");
> + symbol_conf.no_buildid_mmap2 = true;
> + } else if (rec->buildid_mmap_set) {
> + /*
> + * Explicitly passing --buildid-mmap disables buildid processing
> + * and cache generation.
> + */
> + rec->no_buildid = true;
> + }
> + if (rec->buildid_mmap && !perf_can_record_build_id()) {
> + pr_warning("Missing support for build id in kernel mmap events. Disable this warning with --no-buildid-mmap\n");
This can be in two lines. I can make the changes if you're ok.
Thanks,
Namhyung
> + rec->buildid_mmap = false;
> + }
> if (rec->buildid_mmap) {
> - if (!perf_can_record_build_id()) {
> - pr_err("Failed: no support to record build id in mmap events, update your kernel.\n");
> - err = -EINVAL;
> - goto out_opts;
> - }
> - pr_debug("Enabling build id in mmap2 events.\n");
> - /* Enable mmap build id synthesizing. */
> - symbol_conf.buildid_mmap2 = true;
> /* Enable perf_event_attr::build_id bit. */
> rec->opts.build_id = true;
> - /* Disable build id cache. */
> - rec->no_buildid = true;
> }
>
> if (rec->opts.record_cgroup && !perf_can_record_cgroup()) {
> diff --git a/tools/perf/util/symbol_conf.h b/tools/perf/util/symbol_conf.h
> index cd9aa82c7d5a..7a80d2c14d9b 100644
> --- a/tools/perf/util/symbol_conf.h
> +++ b/tools/perf/util/symbol_conf.h
> @@ -43,7 +43,7 @@ struct symbol_conf {
> report_individual_block,
> inline_name,
> disable_add2line_warn,
> - buildid_mmap2,
> + no_buildid_mmap2,
> guest_code,
> lazy_load_kernel_maps,
> keep_exited_threads,
> diff --git a/tools/perf/util/synthetic-events.c b/tools/perf/util/synthetic-events.c
> index 69b98023ce74..638d7dd7fa4b 100644
> --- a/tools/perf/util/synthetic-events.c
> +++ b/tools/perf/util/synthetic-events.c
> @@ -532,7 +532,7 @@ int perf_event__synthesize_mmap_events(const struct perf_tool *tool,
> event->mmap2.pid = tgid;
> event->mmap2.tid = pid;
>
> - if (symbol_conf.buildid_mmap2)
> + if (!symbol_conf.no_buildid_mmap2)
> perf_record_mmap2__read_build_id(&event->mmap2, machine, false);
>
> if (perf_tool__process_synth_event(tool, event, machine, process) != 0) {
> @@ -690,7 +690,7 @@ static int perf_event__synthesize_modules_maps_cb(struct map *map, void *data)
> return 0;
>
> dso = map__dso(map);
> - if (symbol_conf.buildid_mmap2) {
> + if (!symbol_conf.no_buildid_mmap2) {
> size = PERF_ALIGN(dso__long_name_len(dso) + 1, sizeof(u64));
> event->mmap2.header.type = PERF_RECORD_MMAP2;
> event->mmap2.header.size = (sizeof(event->mmap2) -
> @@ -734,9 +734,9 @@ int perf_event__synthesize_modules(const struct perf_tool *tool, perf_event__han
> .process = process,
> .machine = machine,
> };
> - size_t size = symbol_conf.buildid_mmap2
> - ? sizeof(args.event->mmap2)
> - : sizeof(args.event->mmap);
> + size_t size = symbol_conf.no_buildid_mmap2
> + ? sizeof(args.event->mmap)
> + : sizeof(args.event->mmap2);
>
> args.event = zalloc(size + machine->id_hdr_size);
> if (args.event == NULL) {
> @@ -1124,8 +1124,8 @@ static int __perf_event__synthesize_kernel_mmap(const struct perf_tool *tool,
> struct machine *machine)
> {
> union perf_event *event;
> - size_t size = symbol_conf.buildid_mmap2 ?
> - sizeof(event->mmap2) : sizeof(event->mmap);
> + size_t size = symbol_conf.no_buildid_mmap2 ?
> + sizeof(event->mmap) : sizeof(event->mmap2);
> struct map *map = machine__kernel_map(machine);
> struct kmap *kmap;
> int err;
> @@ -1159,7 +1159,7 @@ static int __perf_event__synthesize_kernel_mmap(const struct perf_tool *tool,
> event->header.misc = PERF_RECORD_MISC_GUEST_KERNEL;
> }
>
> - if (symbol_conf.buildid_mmap2) {
> + if (!symbol_conf.no_buildid_mmap2) {
> size = snprintf(event->mmap2.filename, sizeof(event->mmap2.filename),
> "%s%s", machine->mmap_name, kmap->ref_reloc_sym->name) + 1;
> size = PERF_ALIGN(size, sizeof(u64));
> --
> 2.50.0.727.gbf7dc18ff4-goog
>
next prev parent reply other threads:[~2025-07-01 5:43 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-28 4:49 [PATCH v5 00/23] perf: Make code more generic with modern defaults Ian Rogers
2025-06-28 4:49 ` [PATCH v5 01/23] perf build-id: Reduce size of "size" variable Ian Rogers
2025-06-28 4:49 ` [PATCH v5 02/23] perf build-id: Truncate to avoid overflowing the build_id data Ian Rogers
2025-06-28 4:49 ` [PATCH v5 03/23] perf build-id: Change sprintf functions to snprintf Ian Rogers
2025-07-01 16:51 ` Namhyung Kim
2025-06-28 4:49 ` [PATCH v5 04/23] perf build-id: Mark DSO in sample callchains Ian Rogers
2025-06-28 4:49 ` [PATCH v5 05/23] perf build-id: Ensure struct build_id is empty before use Ian Rogers
2025-06-28 4:50 ` [PATCH v5 06/23] perf dso: Move build_id to dso_id Ian Rogers
2025-06-28 4:50 ` [PATCH v5 07/23] perf jitdump: Directly mark the jitdump DSO Ian Rogers
2025-06-28 4:50 ` [PATCH v5 08/23] perf record: Make --buildid-mmap the default Ian Rogers
2025-07-01 5:43 ` Namhyung Kim [this message]
2025-06-28 4:50 ` [PATCH v5 09/23] perf session: Add accessor for session->header.env Ian Rogers
2025-06-28 4:50 ` [PATCH v5 10/23] perf session: Add an env pointer for the current perf_env Ian Rogers
2025-07-01 6:27 ` Namhyung Kim
2025-07-01 17:00 ` Ian Rogers
2025-06-28 4:50 ` [PATCH v5 11/23] perf evlist: Change env variable to session Ian Rogers
2025-07-01 6:31 ` Namhyung Kim
2025-06-28 4:50 ` [PATCH v5 12/23] perf header: Clean up use of perf_env Ian Rogers
2025-06-28 4:50 ` [PATCH v5 13/23] perf test: Avoid use perf_env Ian Rogers
2025-06-28 4:50 ` [PATCH v5 14/23] perf session: Add host_env argument to perf_session__new Ian Rogers
2025-06-28 4:50 ` [PATCH v5 15/23] perf top: Make perf_env locally scoped Ian Rogers
2025-06-28 4:50 ` [PATCH v5 16/23] perf bench synthesize: Avoid use of global perf_env Ian Rogers
2025-07-01 6:05 ` Namhyung Kim
2025-06-28 4:50 ` [PATCH v5 17/23] perf machine: Explicitly pass in host perf_env Ian Rogers
2025-06-28 4:50 ` [PATCH v5 18/23] perf auxtrace: Pass perf_env from session through to mmap read Ian Rogers
2025-06-28 4:50 ` [PATCH v5 19/23] perf trace: Avoid global perf_env with evsel__env Ian Rogers
2025-06-28 4:50 ` [PATCH v5 20/23] perf env: Remove global perf_env Ian Rogers
2025-06-28 4:50 ` [PATCH v5 21/23] perf sample: Remove arch notion of sample parsing Ian Rogers
2025-06-28 4:50 ` [PATCH v5 22/23] perf test: Move PERF_SAMPLE_WEIGHT_STRUCT parsing to common test Ian Rogers
2025-06-28 4:50 ` [PATCH v5 23/23] perf sort: Use perf_env to set arch sort keys and header Ian Rogers
2025-07-01 6:23 ` Namhyung Kim
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=aGN1iPzoeNVxW5fQ@google.com \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=atrajeev@linux.ibm.com \
--cc=ben.gainey@arm.com \
--cc=chaitanyas.prakash@arm.com \
--cc=charlie@rivosinc.com \
--cc=colin.i.king@gmail.com \
--cc=ctshao@google.com \
--cc=dvyukov@google.com \
--cc=fzczx123@gmail.com \
--cc=graham.woodward@arm.com \
--cc=howardchu95@gmail.com \
--cc=ilkka@os.amperecomputing.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=john.g.garry@oracle.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=kjain@linux.ibm.com \
--cc=krzysztof.m.lopatowski@gmail.com \
--cc=leo.yan@linux.dev \
--cc=lihuafei1@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux@treblig.org \
--cc=m.liska@foxlink.cz \
--cc=mark.rutland@arm.com \
--cc=martin.liska@hey.com \
--cc=matt@readmodwrite.com \
--cc=mhiramat@kernel.org \
--cc=mike.leach@linaro.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=quic_zhonhan@quicinc.com \
--cc=ravi.bangoria@amd.com \
--cc=scclevenger@os.amperecomputing.com \
--cc=sesse@google.com \
--cc=song@kernel.org \
--cc=stephen.s.brennan@oracle.com \
--cc=thomas.falcon@intel.com \
--cc=vmolnaro@redhat.com \
--cc=weilin.wang@intel.com \
--cc=will@kernel.org \
--cc=yangyicong@hisilicon.com \
--cc=yeoreum.yun@arm.com \
--cc=yujie.liu@intel.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;
as well as URLs for NNTP newsgroup(s).