public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Serhei Makarov <serhei@serhei.io>
To: irogers@google.com
Cc: acme@kernel.org, aditya.b1@linux.ibm.com,
	adrian.hunter@intel.com, ak@linux.intel.com, alex@ghiti.fr,
	aou@eecs.berkeley.edu, atrajeev@linux.ibm.com, ctshao@google.com,
	dvyukov@google.com, guoren@kernel.org, haibo1.xu@intel.com,
	howardchu95@gmail.com, james.clark@linaro.org,
	john.g.garry@oracle.com, jolsa@kernel.org,
	krzysztof.m.lopatowski@gmail.com, leo.yan@linux.dev,
	linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	linux-riscv@lists.infradead.org, linux@treblig.org,
	mark@klomp.org, mingo@redhat.com, namhyung@kernel.org,
	palmer@dabbelt.com, peterz@infradead.org, pjw@kernel.org,
	shimin.guo@skydio.com, slyich@gmail.com,
	stephen.s.brennan@oracle.com, thomas.falcon@intel.com,
	will@kernel.org
Subject: Re: [PATCH v1 22/23] perf unwind-libdw: Don't discard loaded ELF/Dwarf  after every unwind
Date: Tue, 27 Jan 2026 12:42:53 -0500	[thread overview]
Message-ID: <20260127174253.396766-1-serhei@serhei.io> (raw)
In-Reply-To: <20260117052849.2205545-23-irogers@google.com>

> As removing the dwfl didn't prove possible, an alternative is to just not discard the dwfl when the unwind ends. The dwfl is valid for a process unless a dso is loaded at the same address as a previous one. So keep the dwfl with the maps, invalidate it if a map is removed (in case a new map replaces it) and recycle the dwfl in the unwinding code.

Relevant note:

I'm looking at whether elfutils libdwfl_stacktrace might further help with these issues. The libdwfl_stacktrace library is currently shipped as an experimental addon to libdwfl in elfutils 0.194, but I'm intending to stabilize the API this year. There's code for some analogous functions: translating perf->dwarf register files, and caching Dwfl and Elf data to speed up unwinding across multiple processes. (Thus, if unwinding a collection of perf_events from 16 processes that use libc, we don't need to load the CFI for libc.so 16 times.)

I think once I've stabilized the libdwfl_stacktrace API and expanded the register support to a larger set of perf-supported architectures, it makes sense for me to author a corresponding set of patches for perf. I'll see if it's worth adding more libdwflst functionality to elfutils 0.195 in anticipation of this.

-- Serhei Makarov


  reply	other threads:[~2026-01-27 17:43 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-17  5:28 [PATCH v1 00/23] perf dwarf/libdw extra support, speed and clean ups Ian Rogers
2026-01-17  5:28 ` [PATCH v1 01/23] perf symbol-elf: Fix leak of ELF files with GNU debugdata Ian Rogers
2026-01-17  5:28 ` [PATCH v1 02/23] perf dso: Extra validity checks that e_machine is valid Ian Rogers
2026-01-17  5:28 ` [PATCH v1 03/23] perf record: Disable inline frames when marking build IDs Ian Rogers
2026-01-17  5:28 ` [PATCH v1 04/23] perf unwind-libdw: fix a cross-arch unwinding bug Ian Rogers
2026-01-20 16:02   ` Arnaldo Carvalho de Melo
2026-01-20 17:53     ` Ian Rogers
2026-01-17  5:28 ` [PATCH v1 05/23] perf libdw_addr2line: Fixes to srcline memory allocation Ian Rogers
2026-01-17  5:28 ` [PATCH v1 06/23] perf unwind-libdw: Correct argument to dwfl_attach_state Ian Rogers
2026-01-17  5:28 ` [PATCH v1 07/23] perf powerpc: Unify the skip-callchain-idx libdw with that for addr2line Ian Rogers
2026-01-17  5:28 ` [PATCH v1 08/23] perf perf_regs: Switch from arch string to int e_machine Ian Rogers
2026-01-20 18:49   ` Arnaldo Carvalho de Melo
2026-01-21  6:58     ` Mi, Dapeng
2026-01-21  7:10       ` Ian Rogers
2026-01-17  5:28 ` [PATCH v1 09/23] perf dwarf-regs: Add util/dwarf-regs-arch for consistency with perf-regs Ian Rogers
2026-01-17  5:28 ` [PATCH v1 10/23] perf dwarf-regs: Remove get_arch_regnum Ian Rogers
2026-01-17  5:28 ` [PATCH v1 11/23] perf dwarf-regs: Clean up x86 dwarf_regnum code Ian Rogers
2026-01-17  5:28 ` [PATCH v1 12/23] perf dwarf-regs: Add get_dwarf_regnum_for_perf_regnum and use for x86 unwinding Ian Rogers
2026-01-17  5:42   ` Ian Rogers
2026-01-17  5:28 ` [PATCH v1 13/23] perf dwarf-regs: Add basic get_dwarf_regnum for most architectures Ian Rogers
2026-01-17  5:28 ` [PATCH v1 14/23] perf dwarf-regs: Add ARM perf to dwarf register number mapping functions Ian Rogers
2026-01-17  5:28 ` [PATCH v1 15/23] perf dwarf-regs: Add csky " Ian Rogers
2026-01-17  5:28 ` [PATCH v1 16/23] perf dwarf-regs: Add loongarch " Ian Rogers
2026-01-17  5:28 ` [PATCH v1 17/23] perf dwarf-regs: Add powerpc " Ian Rogers
2026-01-17  5:28 ` [PATCH v1 18/23] perf dwarf-regs: Add RISC-V " Ian Rogers
2026-01-17  5:28 ` [PATCH v1 19/23] perf dwarf-regs: Add S390 " Ian Rogers
2026-01-17  5:28 ` [PATCH v1 20/23] perf dwarf-regs: Add MIPS " Ian Rogers
2026-01-17  5:28 ` [PATCH v1 21/23] perf build: Remove NO_LIBDW_DWARF_UNWIND option Ian Rogers
2026-01-17  5:28 ` [PATCH v1 22/23] perf unwind-libdw: Don't discard loaded ELF/Dwarf after every unwind Ian Rogers
2026-01-27 17:42   ` Serhei Makarov [this message]
2026-01-27 18:08     ` Ian Rogers
2026-01-17  5:28 ` [PATCH v1 23/23] perf machine: Add inline information to frame pointer and LBR callchains Ian Rogers

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=20260127174253.396766-1-serhei@serhei.io \
    --to=serhei@serhei.io \
    --cc=acme@kernel.org \
    --cc=aditya.b1@linux.ibm.com \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=atrajeev@linux.ibm.com \
    --cc=ctshao@google.com \
    --cc=dvyukov@google.com \
    --cc=guoren@kernel.org \
    --cc=haibo1.xu@intel.com \
    --cc=howardchu95@gmail.com \
    --cc=irogers@google.com \
    --cc=james.clark@linaro.org \
    --cc=john.g.garry@oracle.com \
    --cc=jolsa@kernel.org \
    --cc=krzysztof.m.lopatowski@gmail.com \
    --cc=leo.yan@linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-csky@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux@treblig.org \
    --cc=mark@klomp.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=peterz@infradead.org \
    --cc=pjw@kernel.org \
    --cc=shimin.guo@skydio.com \
    --cc=slyich@gmail.com \
    --cc=stephen.s.brennan@oracle.com \
    --cc=thomas.falcon@intel.com \
    --cc=will@kernel.org \
    /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