Re: [PATCH v2 00/22] Start aligning perf test with kunit style

[Jiri Olsa]

On Thu, Oct 28, 2021 at 04:52:13PM -0700, Ian Rogers wrote:
> On Wed, Oct 20, 2021 at 8:51 AM Ian Rogers <irogers@xxxxxxxxxx> wrote:
> >
> > On Wed, Oct 20, 2021 at 5:14 AM Jiri Olsa <jolsa@xxxxxxxxxx> wrote:
> > >
> > > On Wed, Oct 13, 2021 at 10:45:42AM -0700, Ian Rogers wrote:
> > > > Perf test uses its own structs and code layout that differs from kunit
> > > > that was more recently introduced to the kernel. Besides consistency,
> > > > it is hoped that moving in the direction of kunit style will enable
> > > > reuse of infrastructure like test output formatting for continuous
> > > > testing systems. For example:
> > > > https://lore.kernel.org/linux-kselftest/CA+GJov6tdjvY9x12JsJT14qn6c7NViJxqaJk+r-K1YJzPggFDQ@xxxxxxxxxxxxxx/
> > > >
> > > > The motivation for this restructuring comes from wanting to be able to
> > > > tag tests with a size:
> > > > https://lore.kernel.org/linux-perf-users/CAP-5=fWmGyuqFKc-EMP3rbmTkjZ3MS+YSajGZfeRMc38HS82gw@xxxxxxxxxxxxxx/
> > > > To have more exhaustive and slower running tests.  This isn't
> > > > something kunit currently supports, nor is the execution of python and
> > > > shell tests, but it seems sensible to work on an approach with kunit
> > > > rather to invent a new wheel inside of perf.
> > > >
> > > > These initial patches are just refactoring the main test suite
> > > > definitions to be in a more kunit style. Kunit isn't depended upon, it
> > > > is hoped that this can be done in later patches for the sake of
> > > > consistency.
> > > >
> > > > v2. Gets to a point of the perf test test suite/case structs being
> > > >     close facsimiles of the kunit ones. It also addresses feedback on
> > > >     the v1 RFC, in particular from Jiri Olsa <jolsa@xxxxxxxxxx>.
> > >
> > > hi,
> > > when I compile with DEBUG=1 it's ok, but with just make:
> > >
> > > [root@krava perf]# ./perf test
> > > Segmentation fault (core dumped)
> > > [root@krava perf]# gdb ./perf
> > > GNU gdb (GDB) Fedora 10.2-4.fc33
> > > Copyright (C) 2021 Free Software Foundation, Inc.
> > > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> > > This is free software: you are free to change and redistribute it.
> > > There is NO WARRANTY, to the extent permitted by law.
> > > Type "show copying" and "show warranty" for details.
> > > This GDB was configured as "x86_64-redhat-linux-gnu".
> > > Type "show configuration" for configuration details.
> > > For bug reporting instructions, please see:
> > > <https://www.gnu.org/software/gdb/bugs/>.
> > > Find the GDB manual and other documentation resources online at:
> > >     <http://www.gnu.org/software/gdb/documentation/>.
> > >
> > > For help, type "help".
> > > Type "apropos word" to search for commands related to "word"...
> > > Reading symbols from ./perf...
> > > (gdb) r test
> > > Starting program: /home/jolsa/kernel/linux-perf/tools/perf/perf test
> > > [Thread debugging using libthread_db enabled]
> > > Using host libthread_db library "/lib64/libthread_db.so.1".
> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> > > __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:96
> > > 96              VPCMPEQ (%rdi), %ymm0, %ymm1
> > > Missing separate debuginfos, use: dnf debuginfo-install bzip2-libs-1.0.8-4.fc33.x86_64 cyrus-sasl-lib-2.1.27-6.fc33.x86_64 elfutils-debuginfod-client-0.185-2.fc33.x86_64 elfutils-libelf-0.185-2.fc33.x86_64 elfutils-libs-0.185-2.fc33.x86_64 keyutils-libs-1.6.1-1.fc33.x86_64 krb5-libs-1.18.2-31.fc33.x86_64 libbabeltrace-1.5.8-3.fc33.x86_64 libbrotli-1.0.9-3.fc33.x86_64 libcap-2.48-2.fc33.x86_64 libcom_err-1.45.6-4.fc33.x86_64 libgcc-10.3.1-1.fc33.x86_64 libidn2-2.3.2-1.fc33.x86_64 libnghttp2-1.43.0-1.fc33.x86_64 libpsl-0.21.1-2.fc33.x86_64 libselinux-3.1-2.fc33.x86_64 libssh-0.9.6-1.fc33.x86_64 libunistring-0.9.10-9.fc33.x86_64 libunwind-1.4.0-4.fc33.x86_64 libuuid-2.36.1-1.fc33.x86_64 libxcrypt-4.4.26-2.fc33.x86_64 numactl-libs-2.0.14-1.fc33.x86_64 openldap-2.4.50-5.fc33.x86_64 openssl-libs-1.1.1l-2.fc33.x86_64 pcre-8.44-2.fc33.x86_64 perl-libs-5.32.1-471.fc33.x86_64 popt-1.18-2.fc33.x86_64 python2.7-2.7.18-15.fc33.x86_64 slang-2.3.2-8.fc33.x86_64 xz-libs-5.2.5-4.fc33.x86_64 zlib-1.2.11-23.fc33.x86_64
> > > (gdb) bt
> > > #0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:96
> > > #1  0x00000000004a3848 in __cmd_test (skiplist=0x0, argv=0x7fffffffd6c0, argc=0) at tests/builtin-test.c:150
> > > #2  cmd_test (argc=0, argv=0x7fffffffd6c0) at tests/builtin-test.c:628
> > > #3  0x00000000004cc47b in run_builtin (p=p@entry=0xa7cda8 <commands+552>, argc=argc@entry=1, argv=argv@entry=0x7fffffffd6c0) at perf.c:313
> > > #4  0x00000000004397ae in handle_internal_command (argv=0x7fffffffd6c0, argc=1) at perf.c:365
> > > #5  run_argv (argv=<synthetic pointer>, argcp=<synthetic pointer>) at perf.c:409
> > > #6  main (argc=1, argv=0x7fffffffd6c0) at perf.c:539
> > > (gdb)
> >
> > Thanks, I'll take a look.
> 
> I wasn't able to reproduce this, I tried with gcc-10 on each patch
> individually, debug disabled and O3. I can send a v3 patch set, but
> currently it is just a rebase of v2.

ok, I'll try to debug that if I can still reproduce

jirka