Skip to content
  1. Apr 11, 2022
  2. Apr 10, 2022
  3. Apr 09, 2022
    • Athira Rajeev's avatar
      perf bench: Fix epoll bench to correct usage of affinity for machines with #CPUs > 1K · 299687e1
      Athira Rajeev authored
      
      
      The 'perf bench epoll' testcase fails on systems with more than 1K CPUs.
      
      Testcase: perf bench epoll all
      
      Result snippet:
      <<>>
      Run summary [PID 106497]: 1399 threads monitoring on 64 file-descriptors for 8 secs.
      
      perf: pthread_create: No such file or directory
      <<>>
      
      In epoll benchmarks (ctl, wait) pthread_create is invoked in do_threads
      from respective bench_epoll_*  function. Though the logs shows direct
      failure from pthread_create, the actual failure is from
      "sched_setaffinity" returning EINVAL (invalid argument).
      
      This happens because the default mask size in glibc is 1024. To overcome
      this 1024 CPUs mask size limitation of cpu_set_t, change the mask size
      using the CPU_*_S macros.
      
      Patch addresses this by fixing all the epoll benchmarks to use CPU_ALLOC
      to allocate cpumask, CPU_ALLOC_SIZE for size, and CPU_SET_S to set the
      mask.
      
      Reported-by: default avatarDisha Goel <disgoel@linux.vnet.ibm.com>
      Signed-off-by: default avatarAthira Jajeev <atrajeev@linux.vnet.ibm.com>
      Tested-by: default avatarDisha Goel <disgoel@linux.vnet.ibm.com>
      Acked-by: default avatarIan Rogers <irogers@google.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kajol Jain <kjain@linux.ibm.com>
      Cc: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Nageswara R Sastry <rnsastry@linux.ibm.com>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Link: https://lore.kernel.org/r/20220406175113.87881-3-atrajeev@linux.vnet.ibm.com
      
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      299687e1
    • Athira Rajeev's avatar
      perf bench: Fix futex bench to correct usage of affinity for machines with #CPUs > 1K · c9c2a427
      Athira Rajeev authored
      
      
      The 'perf bench futex' testcase fails on systems with more than 1K CPUs.
      
      Testcase: perf bench futex all
      
      Failure snippet:
      <<>>Running futex/hash benchmark...
      
      perf: pthread_create: No such file or directory
      <<>>
      
      All the futex benchmarks (ie hash, lock-api, requeue, wake,
      wake-parallel), pthread_create is invoked in respective bench_futex_*
      function. Though the logs shows direct failure from pthread_create,
      strace logs showed that actual failure is from  "sched_setaffinity"
      returning EINVAL (invalid argument).
      
      This happens because the default mask size in glibc is 1024. To overcome
      this 1024 CPUs mask size limitation of cpu_set_t, change the mask size
      using the CPU_*_S macros.
      
      Patch addresses this by fixing all the futex benchmarks to use CPU_ALLOC
      to allocate cpumask, CPU_ALLOC_SIZE for size, and CPU_SET_S to set the
      mask.
      
      Reported-by: default avatarDisha Goel <disgoel@linux.vnet.ibm.com>
      Reviewed-by: default avatarSrikar Dronamraju <srikar@linux.vnet.ibm.com>
      Signed-off-by: default avatarAthira Jajeev <atrajeev@linux.vnet.ibm.com>
      Tested-by: default avatarDisha Goel <disgoel@linux.vnet.ibm.com>
      Acked-by: default avatarIan Rogers <irogers@google.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kajol Jain <kjain@linux.ibm.com>
      Cc: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Nageswara R Sastry <rnsastry@linux.ibm.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Link: https://lore.kernel.org/r/20220406175113.87881-2-atrajeev@linux.vnet.ibm.com
      
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      c9c2a427
    • Adrian Hunter's avatar
      perf tools: Fix perf's libperf_print callback · aeee9dc5
      Adrian Hunter authored
      
      
      eprintf() does not expect va_list as the type of the 4th parameter.
      
      Use veprintf() because it does.
      
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Fixes: 428dab81 ("libperf: Merge libperf_set_print() into libperf_init()")
      Cc: Jiri Olsa <jolsa@kernel.org>
      Link: https://lore.kernel.org/r/20220408132625.2451452-1-adrian.hunter@intel.com
      
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      aeee9dc5
    • James Clark's avatar
      perf: arm-spe: Fix perf report --mem-mode · ffab4870
      James Clark authored
      
      
      Since commit bb30acae ("perf report: Bail out --mem-mode if mem
      info is not available") "perf mem report" and "perf report --mem-mode"
      don't allow opening the file unless one of the events has
      PERF_SAMPLE_DATA_SRC set.
      
      SPE doesn't have this set even though synthetic memory data is generated
      after it is decoded. Fix this issue by setting DATA_SRC on SPE events.
      This has no effect on the data collected because the SPE driver doesn't
      do anything with that flag and doesn't generate samples.
      
      Fixes: bb30acae ("perf report: Bail out --mem-mode if mem info is not available")
      Signed-off-by: default avatarJames Clark <james.clark@arm.com>
      Tested-by: default avatarLeo Yan <leo.yan@linaro.org>
      Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: German Gomez <german.gomez@arm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: John Garry <john.garry@huawei.com>
      Cc: Leo Yan <leo.yan@linaro.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Will Deacon <will@kernel.org>
      Link: https://lore.kernel.org/r/20220408144056.1955535-1-james.clark@arm.com
      
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      ffab4870
    • James Clark's avatar
      perf unwind: Don't show unwind error messages when augmenting frame pointer stack · fa7095c5
      James Clark authored
      
      
      Commit Fixes: b9f6fbb3 ("perf arm64: Inject missing frames when
      using 'perf record --call-graph=fp'") intended to add a 'best effort'
      DWARF unwind that improved the frame pointer stack in most scenarios.
      
      It's expected that the unwind will fail sometimes, but this shouldn't be
      reported as an error. It only works when the return address can be
      determined from the contents of the link register alone.
      
      Fix the error shown when the unwinder requires extra registers by adding
      a new flag that suppresses error messages. This flag is not set in the
      normal --call-graph=dwarf unwind mode so that behavior is not changed.
      
      Fixes: b9f6fbb3 ("perf arm64: Inject missing frames when using 'perf record --call-graph=fp'")
      Reported-by: default avatarJohn Garry <john.garry@huawei.com>
      Signed-off-by: default avatarJames Clark <james.clark@arm.com>
      Tested-by: default avatarJohn Garry <john.garry@huawei.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexandre Truong <alexandre.truong@arm.com>
      Cc: German Gomez <german.gomez@arm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: https://lore.kernel.org/r/20220406145651.1392529-1-james.clark@arm.com
      
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      fa7095c5
    • Arnaldo Carvalho de Melo's avatar
      tools headers arm64: Sync arm64's cputype.h with the kernel sources · 278aaba2
      Arnaldo Carvalho de Melo authored
      To get the changes in:
      
        83bea32a ("arm64: Add part number for Arm Cortex-A78AE")
      
      That addresses this perf build warning:
      
        Warning: Kernel ABI header at 'tools/arch/arm64/include/asm/cputype.h' differs from latest version at 'arch/arm64/include/asm/cputype.h'
        diff -u tools/arch/arm64/include/asm/cputype.h arch/arm64/include/asm/cputype.h
      
      Cc: Ali Saidi <alisaidi@amazon.com>
      Cc: Andrew Kilroy <andrew.kilroy@arm.com>
      Cc: Chanho Park <chanho61.park@samsung.com>
      Cc: German Gomez <german.gomez@arm.com>
      Cc: James Clark <james.clark@arm.com>
      Cc: John Garry <john.garry@huawei.com>
      Cc: Leo Yan <leo.yan@linaro.org>
      Cc: Will Deacon <will@kernel.org>
      Link: http://lore.kernel.org/lkml/
      
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      278aaba2
    • Chengdong Li's avatar
      perf test tsc: Fix error message when not supported · 290fa68b
      Chengdong Li authored
      
      
      By default `perf test tsc` does not return the error message when the
      child process detected kernel does not support it. Instead, the child
      process prints an error message to stderr, unfortunately stderr is
      redirected to /dev/null when verbose <= 0.
      
      This patch does:
      
      - return TEST_SKIP to the parent process instead of TEST_OK when
        perf_read_tsc_conversion() is not supported.
      
      - Add a new subtest of testing if TSC is supported on current
        architecture by moving exist code to a separate function.
        It avoids two places in test__perf_time_to_tsc() that return
        TEST_SKIP by doing this.
      
      - Extend the test suite definition to contain above two subtests.
        Current test_suite and test_case structs do not support printing skip
        reason when the number of subtest less than 1. To print skip reason, it
        is necessary to extend current test suite definition.
      
      Reviewed-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarChengdong Li <chengdongli@tencent.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: likexu@tencent.com
      Link: https://lore.kernel.org/r/20220408084748.43707-1-chengdongli@tencent.com
      
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      290fa68b
    • Arnaldo Carvalho de Melo's avatar
      perf build: Don't use -ffat-lto-objects in the python feature test when building with clang-13 · 3a8a0475
      Arnaldo Carvalho de Melo authored
      
      
      Using -ffat-lto-objects in the python feature test when building with
      clang-13 results in:
      
        clang-13: error: optimization flag '-ffat-lto-objects' is not supported [-Werror,-Wignored-optimization-argument]
        error: command '/usr/sbin/clang' failed with exit code 1
        cp: cannot stat '/tmp/build/perf/python_ext_build/lib/perf*.so': No such file or directory
        make[2]: *** [Makefile.perf:639: /tmp/build/perf/python/perf.so] Error 1
      
      Noticed when building on a docker.io/library/archlinux:base container.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Fangrui Song <maskray@google.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: John Keeping <john@metanate.com>
      Cc: Leo Yan <leo.yan@linaro.org>
      Cc: Michael Petlan <mpetlan@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Nathan Chancellor <nathan@kernel.org>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Cc: Sedat Dilek <sedat.dilek@gmail.com>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      3a8a0475
    • Arnaldo Carvalho de Melo's avatar
      perf python: Fix probing for some clang command line options · dd6e1fe9
      Arnaldo Carvalho de Melo authored
      The clang compiler complains about some options even without a source
      file being available, while others require one, so use the simple
      tools/build/feature/test-hello.c file.
      
      Then check for the "is not supported" string in its output, in addition
      to the "unknown argument" already being looked for.
      
      This was noticed when building with clang-13 where -ffat-lto-objects
      isn't supported and since we were looking just for "unknown argument"
      and not providing a source code to clang, was mistakenly assumed as
      being available and not being filtered to set of command line options
      provided to clang, leading to a build failure.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Fangrui Song <maskray@google.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: John Keeping <john@metanate.com>
      Cc: Leo Yan <leo.yan@linaro.org>
      Cc: Michael Petlan <mpetlan@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Nathan Chancellor <nathan@kernel.org>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Cc: Sedat Dilek <sedat.dilek@gmail.com>
      Link: http://lore.kernel.org/lkml/
      
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      dd6e1fe9
    • Arnaldo Carvalho de Melo's avatar
      tools build: Filter out options and warnings not supported by clang · 41caff45
      Arnaldo Carvalho de Melo authored
      These make the feature check fail when using clang, so remove them just
      like is done in tools/perf/Makefile.config to build perf itself.
      
      Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config
      when building with clang is also necessary to avoid these warnings
      turned into errors (-Werror):
      
          CC      /tmp/build/perf/util/scripting-engines/trace-event-perl.o
        In file included from util/scripting-engines/trace-event-perl.c:35:
        In file included from /usr/lib64/perl5/CORE/perl.h:4085:
        In file included from /usr/lib64/perl5/CORE/hv.h:659:
        In file included from /usr/lib64/perl5/CORE/hv_func.h:34:
        In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4:
        /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
            ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
        #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                             ^~~~~~~~~~
        /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START'
        #   define STMT_START   (void)( /* gcc supports "({ STATEMENTS; })" */
                                      ^
        /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here
            ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
        #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START {  \
                                                        ^
        /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro]
            ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
            v ^= (v>>23);                       \
                                                ^
        /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here
            ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b);
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32'
        } STMT_END
          ^~~~~~~~
        /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END'
        #   define STMT_END     )
                                ^
      
      Please refer to the discussion on the Link: tag below, where Nathan
      clarifies the situation:
      
      <quote>
      acme> And then get to the problems at the end of this message, which seem
      acme> similar to the problem described here:
      acme>
      acme> From  Nathan Chancellor <>
      acme> Subject	[PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
      acme>
      acme> https://lkml.org/lkml/2020/9/1/135
      acme>
      acme> So perhaps in this case its better to disable that
      acme> -Werror,-Wcompound-token-split-by-macro when building with clang?
      
      Yes, I think that is probably the best solution. As far as I can tell,
      at least in this file and context, the warning appears harmless, as the
      "create a GNU C statement expression from two different macros" is very
      much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS.
      The warning is fixed in upstream Perl by just avoiding creating GNU C
      statement expressions using STMT_START and STMT_END:
      
        https://github.com/Perl/perl5/issues/18780
        https://github.com/Perl/perl5/pull/18984
      
      
      
      If I am reading the source code correctly, an alternative to disabling
      the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it
      seems like that might end up impacting more than just this site,
      according to the issue discussion above.
      </quote>
      
      Based-on-a-patch-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
      Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # Debian/Selfmade LLVM-14 (x86-64)
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Fangrui Song <maskray@google.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: John Keeping <john@metanate.com>
      Cc: Leo Yan <leo.yan@linaro.org>
      Cc: Michael Petlan <mpetlan@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Nathan Chancellor <nathan@kernel.org>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Link: http://lore.kernel.org/lkml/YkxWcYzph5pC1EK8@kernel.org
      
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      41caff45