From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Kan Liang <kan.liang@linux.intel.com>,
Clark Williams <williams@redhat.com>,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Athira Rajeev <atrajeev@linux.vnet.ibm.com>,
Howard Chu <howardchu95@gmail.com>,
James Clark <james.clark@linaro.org>, Leo Yan <leo.yan@linux.dev>,
Thomas Richter <tmricht@linux.ibm.com>,
Veronika Molnarova <vmolnaro@redhat.com>
Subject: [PATCH 1/2] perf test python: Robustify the 'perf test python' test case
Date: Mon, 4 Nov 2024 14:59:52 -0300 [thread overview]
Message-ID: <20241104175953.535202-2-acme@kernel.org> (raw)
In-Reply-To: <20241104175953.535202-1-acme@kernel.org>
From: Arnaldo Carvalho de Melo <acme@redhat.com>
While working on a patch to not build the 'perf test' entry that tests
the python binding when NO_LIBPYTHON=1 is used when building perf,
meaning that the python binding will not be built, thus no need to test
it, I noticed this inconsistency:
$ perf test 17
17: 'import perf' in python : Ok
$ perf test -F 17
17: 'import perf' in python : Ok
$
$ perf check feature libpython
libpython: [ OFF ] # HAVE_LIBPYTHON_SUPPORT
$ ldd ~/bin/perf | grep python
$
Even without any python binding or support for loading it present in
perf, it says that testing that feature somehow "passes":
$ strace -s1024 -f -e execve perf test 17
execve("/home/acme/bin/perf", ["perf", "test", "17"], 0x7ffe99ae5d50 /* 38 vars */) = 0
strace: Process 519319 attached
17: 'import perf' in python : Running (1 active)
strace: Process 519320 attached
[pid 519320] execve("/bin/sh", ["sh", "-c", "--", "echo \"import sys ; sys.path.insert(0, '/tmp/build/perf-tools-next/python'); import perf\" | 2> /dev/null"], 0x377ba9a0 /* 40 vars */) = 0
strace: Process 519321 attached
strace: Process 519322 attached
[pid 519321] +++ exited with 0 +++
[pid 519322] +++ exited with 0 +++
[pid 519320] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=519321, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
[pid 519320] +++ exited with 0 +++
[pid 519319] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=519320, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
[pid 519319] +++ exited with 0 +++
17: 'import perf' in python : Ok
+++ exited with 0 +++
$
It doesn't matter if we fork a new perf process to run just that test
entry or if we don't:
$ perf test -h -F
Usage: perf test [<options>] [{list <test-name-fragment>|[<test-name-fragments>|<test-numbers>]}]
-F, --dont-fork Do not fork for testcase
$
$ strace -s1024 -f -e execve perf test -F 17
execve("/home/acme/bin/perf", ["perf", "test", "-F", "17"], 0x7ffda8fafed8 /* 38 vars */) = 0
strace: Process 519336 attached
[pid 519336] execve("/bin/sh", ["sh", "-c", "--", "echo \"import sys ; sys.path.insert(0, '/tmp/build/perf-tools-next/python'); import perf\" | 2> /dev/null"], 0x159d99a0 /* 40 vars */) = 0
strace: Process 519337 attached
strace: Process 519338 attached
[pid 519337] +++ exited with 0 +++
[pid 519338] +++ exited with 0 +++
[pid 519336] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=519337, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
[pid 519336] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=519336, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
17: 'import perf' in python : Ok
+++ exited with 0 +++
$
The system() call (that execve) will return zero even with that echo
being piped into nothing:
# sh -c -- echo \"import sys ; sys.path.insert(0, '/tmp/build/perf-tools-next/python'); import perf\" | 2> /dev/null
-bash: syntax error near unexpected token `0,'
# echo $?
2
# sh -c -- echo \"import sys ; sys.path.insert(0, '/tmp/build/perf-tools-next/python'); import perf\" |
-bash: syntax error near unexpected token `0,'
# echo $?
2
#
If we instead avoid the echo and use 'python -c' to pass that simple
python script just trying to load the non-existent perf binding we get
less processes and a more consistent result even in this pathological
case where PYTHON="":
$ perf test 17
17: 'import perf' in python : FAILED!
$ perf test -F 17
17: 'import perf' in python : FAILED!
$
$ perf test -vv 17
Couldn't bump rlimit(MEMLOCK), failures may take place when creating BPF maps, etc
17: 'import perf' in python:
--- start ---
test child forked, pid 522859
python usage test: " -c "import sys ; sys.path.insert(0, '/tmp/build/perf-tools-next/python'); import perf" "
sh: line 1: -c: command not found
---- end(-1) ----
17: 'import perf' in python : FAILED!
$
The next patch will sidestep all this by plain not building the python
binding test when the binding isn't built, i.e. with NO_LIBPYTHON=1.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Cc: Howard Chu <howardchu95@gmail.com>
Cc: Ian Rogers <irogers@google.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Leo Yan <leo.yan@linux.dev>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Thomas Richter <tmricht@linux.ibm.com>
Cc: Veronika Molnarova <vmolnaro@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/tests/python-use.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/tests/python-use.c b/tools/perf/tests/python-use.c
index 0ebc22ac8d5b47ed..b7325caad22bab10 100644
--- a/tools/perf/tests/python-use.c
+++ b/tools/perf/tests/python-use.c
@@ -14,8 +14,8 @@ static int test__python_use(struct test_suite *test __maybe_unused, int subtest
char *cmd;
int ret;
- if (asprintf(&cmd, "echo \"import sys ; sys.path.insert(0, '%s'); import perf\" | %s %s",
- PYTHONPATH, PYTHON, verbose > 0 ? "" : "2> /dev/null") < 0)
+ if (asprintf(&cmd, "%s -c \"import sys ; sys.path.insert(0, '%s'); import perf\" %s",
+ PYTHON, PYTHONPATH, verbose > 0 ? "" : "2> /dev/null") < 0)
return -1;
pr_debug("python usage test: \"%s\"\n", cmd);
--
2.47.0
next prev parent reply other threads:[~2024-11-04 18:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-04 17:59 [PATCH 0/2 perf-tools-next] 'perf test python' fixes/improvements Arnaldo Carvalho de Melo
2024-11-04 17:59 ` Arnaldo Carvalho de Melo [this message]
2024-11-04 20:59 ` [PATCH 1/2] perf test python: Robustify the 'perf test python' test case Ian Rogers
2024-11-04 17:59 ` [PATCH 2/2] perf test: Don't build the python binding builtin test case with NO_LIBPYTHON=1 Arnaldo Carvalho de Melo
2024-11-04 21:02 ` Ian Rogers
2024-11-04 23:30 ` 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=20241104175953.535202-2-acme@kernel.org \
--to=acme@kernel.org \
--cc=acme@redhat.com \
--cc=adrian.hunter@intel.com \
--cc=atrajeev@linux.vnet.ibm.com \
--cc=howardchu95@gmail.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=leo.yan@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=tglx@linutronix.de \
--cc=tmricht@linux.ibm.com \
--cc=vmolnaro@redhat.com \
--cc=williams@redhat.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).