From: Namhyung Kim <namhyung@kernel.org>
To: Ian Rogers <irogers@google.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
James Clark <james.clark@linaro.org>,
Jiri Olsa <jolsa@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-perf-users@vger.kernel.org,
Pablo Galindo <pablogsal@gmail.com>
Subject: Re: [PATCH 2/2] perf test: Add python JIT dump test
Date: Fri, 14 Nov 2025 11:03:23 -0800 [thread overview]
Message-ID: <aRd8-4e5apdL7R6Z@google.com> (raw)
In-Reply-To: <CAP-5=fWLGQJ+jdc1kqSo0+wy6AVa2Dm-yp7OX8q+bNw94aV3FA@mail.gmail.com>
On Fri, Nov 14, 2025 at 09:44:21AM -0800, Ian Rogers wrote:
> On Fri, Nov 14, 2025 at 1:29 AM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > Add a test case for the python interpreter like below so that we can
> > make sure it won't break again. To validate the effect of build-ID
> > generation, it adds and removes the JIT'ed DSOs to/from the build-ID
> > cache for the test.
> >
> > $ perf test -vv jitdump
> > 84: python profiling with jitdump:
> > --- start ---
> > test child forked, pid 214316
> > Run python with -Xperf_jit
> > [ perf record: Woken up 5 times to write data ]
> > [ perf record: Captured and wrote 1.180 MB /tmp/__perf_test.perf.data.XbqZNm (140 samples) ]
> > Generate JIT-ed DSOs using perf inject
> > Add JIT-ed DSOs to the build-ID cache
> > Check the symbol containing the script name
> > Found 108 matching lines
> > Remove JIT-ed DSOs from the build-ID cache
> > ---- end(0) ----
> > 84: python profiling with jitdump : Ok
> >
> > Cc: Pablo Galindo <pablogsal@gmail.com>
> > Link: https://docs.python.org/3/howto/perf_profiling.html#how-to-work-without-frame-pointers
> > Signed-off-by: Namhyung Kim <namhyung@kernel.org>
> > ---
> > tools/perf/tests/shell/jitdump-python.sh | 41 ++++++++++++++++++++++++
> > tools/perf/tests/shell/jitdump-test.py | 14 ++++++++
> > 2 files changed, 55 insertions(+)
> > create mode 100755 tools/perf/tests/shell/jitdump-python.sh
> > create mode 100644 tools/perf/tests/shell/jitdump-test.py
> >
> > diff --git a/tools/perf/tests/shell/jitdump-python.sh b/tools/perf/tests/shell/jitdump-python.sh
> > new file mode 100755
> > index 0000000000000000..101c15e65da1a0c0
> > --- /dev/null
> > +++ b/tools/perf/tests/shell/jitdump-python.sh
> > @@ -0,0 +1,41 @@
> > +#!/bin/bash
> > +# python profiling with jitdump
> > +# SPDX-License-Identifier: GPL-2.0
> > +
> > +if ! command -v python > /dev/null; then
> > + echo "Skip: no python found"
> > + exit 2
> > +fi
>
> Can this just reuse the python set up logic in:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/tests/shell/lib/setup_python.sh?h=perf-tools-next
Will do!
>
> > +
> > +SHELLDIR=$(dirname $0)
> > +PERF_DATA=$(mktemp /tmp/__perf_test.perf.data.XXXXXX)
> > +
> > +echo "Run python with -Xperf_jit"
> > +perf record -k 1 -g --call-graph dwarf -o "${PERF_DATA}" -- python -Xperf_jit ${SHELLDIR}/jitdump-test.py
>
> We can avoid an additional file by using the REPL, this is why the
> java test is using jshell:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/tests/shell/test_java_symbol.sh?h=perf-tools-next#n41
I thought that too, but I wanted a filename to check the result.
Hmm.. probably I can use a different pattern without it.
>
> > +
> > +_PID=$(perf report -i "${PERF_DATA}" -F pid -q -g none | cut -d: -f1 -s)
> > +PID=$(echo -n $_PID) # remove newlines
> > +
> > +echo "Generate JIT-ed DSOs using perf inject"
> > +perf inject -i "${PERF_DATA}" -j -o "${PERF_DATA}.jit"
>
> Thomas Richter did a workaround in the Java version to avoid debuginfod queries:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/tests/shell/test_java_symbol.sh?h=perf-tools-next#n59
Yep, will add.
>
> > +
> > +echo "Add JIT-ed DSOs to the build-ID cache"
> > +for F in /tmp/jitted-${PID}-*.so; do
> > + perf buildid-cache -a "${F}"
> > +done
> > +
> > +echo "Check the symbol containing the script name"
> > +NUM=$(perf report -i "${PERF_DATA}.jit" -s sym | grep -c jitdump-test.py)
> > +
> > +echo "Found ${NUM} matching lines"
> > +
> > +echo "Remove JIT-ed DSOs from the build-ID cache"
> > +for F in /tmp/jitted-${PID}-*.so; do
> > + perf buildid-cache -r "${F}"
> > +done
> > +
> > +rm -f ${PERF_DATA} ${PERF_DATA}.jit /tmp/jit-${PID}.dump /tmp/jitted-${PID}-*.so
>
> It'd be nice to have this in a function that also gets run if there is
> a trap. It looks like the Java test is missing a call to cleanup_files
> on the success path.
I thought that it will go the end of the script regardless of any
command failures but we should protect it from Ctrl-C as well.. ok.
Thanks for your review!
Namhyung
>
> > +
> > +if [ "${NUM}" -eq 0 ]; then
> > + exit 1
> > +fi
> > diff --git a/tools/perf/tests/shell/jitdump-test.py b/tools/perf/tests/shell/jitdump-test.py
> > new file mode 100644
> > index 0000000000000000..b427363ae4956db6
> > --- /dev/null
> > +++ b/tools/perf/tests/shell/jitdump-test.py
> > @@ -0,0 +1,14 @@
> > +def foo(n):
> > + result = 0
> > + for _ in range(n):
> > + result += 1
> > + return result
> > +
> > +def bar(n):
> > + foo(n)
> > +
> > +def baz(n):
> > + bar(n)
> > +
> > +if __name__ == "__main__":
> > + baz(1000000)
> > --
> > 2.52.0.rc1.455.g30608eb744-goog
> >
next prev parent reply other threads:[~2025-11-14 19:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-14 9:29 [PATCH 1/2] perf jitdump: Add load_addr to build-ID generation Namhyung Kim
2025-11-14 9:29 ` [PATCH 2/2] perf test: Add python JIT dump test Namhyung Kim
2025-11-14 17:44 ` Ian Rogers
2025-11-14 19:03 ` Namhyung Kim [this message]
2025-11-14 19:12 ` Pablo Galindo Salgado
2025-11-14 19:23 ` Namhyung Kim
2025-11-14 22:27 ` Pablo Galindo Salgado
2025-11-14 23:27 ` Namhyung Kim
2025-11-14 23:49 ` Pablo Galindo Salgado
2025-11-14 17:33 ` [PATCH 1/2] perf jitdump: Add load_addr to build-ID generation Ian Rogers
2025-11-14 18:57 ` Namhyung Kim
2025-11-14 19:32 ` Ian Rogers
2025-11-14 23:24 ` Namhyung Kim
2025-11-14 23:58 ` Ian Rogers
2025-11-16 7:22 ` Fangrui Song
2025-11-17 16:58 ` 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=aRd8-4e5apdL7R6Z@google.com \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=pablogsal@gmail.com \
--cc=peterz@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.