linux-stable.git/tools/perf/bench, branch v5.18.2

perf bench numa: Address compiler error on s390

2022-05-21T17:45:19+00:00

The compilation on s390 results in this error:

  # make DEBUG=y bench/numa.o
  ...
  bench/numa.c: In function ‘__bench_numa’:
  bench/numa.c:1749:81: error: ‘%d’ directive output may be truncated
              writing between 1 and 11 bytes into a region of size between
              10 and 20 [-Werror=format-truncation=]
  1749 |        snprintf(tname, sizeof(tname), "process%d:thread%d", p, t);
                                                               ^~
  ...
  bench/numa.c:1749:64: note: directive argument in the range
                 [-2147483647, 2147483646]
  ...
  #

The maximum length of the %d replacement is 11 characters because of the
negative sign.  Therefore extend the array by two more characters.

Output after:

  # make  DEBUG=y bench/numa.o > /dev/null 2>&1; ll bench/numa.o
  -rw-r--r-- 1 root root 418320 May 19 09:11 bench/numa.o
  #

Fixes: 3aff8ba0a4c9c919 ("perf bench numa: Avoid possible truncation when using snprintf()")
Suggested-by: Namhyung Kim 
Signed-off-by: Thomas Richter 
Cc: Heiko Carstens 
Cc: Sumanth Korikkar 
Cc: Sven Schnelle 
Cc: Vasily Gorbik 
Link: https://lore.kernel.org/r/20220520081158.2990006-1-tmricht@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo

perf bench: Fix two numa NDEBUG warnings

2022-05-09T00:48:49+00:00

BUG_ON is a no-op if NDEBUG is defined, otherwise it is an assert.
Compiling with NDEBUG yields:

  bench/numa.c: In function ‘bind_to_cpu’:
  bench/numa.c:314:1: error: control reaches end of non-void function [-Werror=return-type]
    314 | }
        | ^
  bench/numa.c: In function ‘bind_to_node’:
  bench/numa.c:367:1: error: control reaches end of non-void function [-Werror=return-type]
    367 | }
        | ^

Add return statements to cover this case.

Reviewed-by: Athira Jajeev 
Signed-off-by: Ian Rogers 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Ingo Molnar 
Cc: Jin Yao 
Cc: Jiri Olsa 
Cc: Mark Rutland 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Xing Zhengjun 
Link: https://lore.kernel.org/r/20220428202912.1056444-1-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo

perf bench: Fix numa bench to fix usage of affinity for machines with #CPUs > 1K

2022-04-14T12:15:10+00:00

The 'perf bench numa' testcase fails on systems with more than 1K CPUs.

Testcase: perf bench numa mem -p 1 -t 3 -P 512 -s 100 -zZ0qcm --thp  1

Snippet of code:

  <<>>
  perf: bench/numa.c:302: bind_to_node: Assertion `!(ret)' failed.
  Aborted (core dumped)
  <<>>

bind_to_node() uses "sched_getaffinity" to save the original cpumask and
this call is 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 ie, use CPU_ALLOC to allocate
cpumask, CPU_ALLOC_SIZE for size.

Apart from fixing this for "orig_mask", apply same logic to "mask" as
well which is used to setaffinity so that mask size is large enough to
represent number of possible CPU's in the system.

sched_getaffinity is used in one more place in perf numa bench. It is in
"bind_to_cpu" function. Apply the same logic there also. Though
currently no failure is reported from there, it is ideal to change
getaffinity to work with such system configurations having CPU's more
than default mask size supported by glibc.

Also fix "sched_setaffinity" to use mask size which is large enough to
represent number of possible CPU's in the system.

Fixed all places where "bind_cpumask" which is part of "struct
thread_data" is used such that bind_cpumask works in all configuration.

Reported-by: Disha Goel 
Signed-off-by: Athira Jajeev 
Cc: Ian Rogers 
Cc: Jiri Olsa 
Cc: Kajol Jain 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Nageswara R Sastry 
Cc: Srikar Dronamraju 
Cc: linuxppc-dev@lists.ozlabs.org
Link: https://lore.kernel.org/r/20220412164059.42654-3-atrajeev@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo

perf bench: Fix numa testcase to check if CPU used to bind task is online

2022-04-14T12:13:41+00:00

Perf numa bench test fails with error:

Testcase:

  ./perf bench numa mem -p 2 -t 1 -P 1024 -C 0,8 -M 1,0 -s 20 -zZq --thp  1 --no-data_rand_walk

Failure snippet:

<<>>
  Running 'numa/mem' benchmark:

  # Running main, "perf bench numa numa-mem -p 2 -t 1 -P 1024 -C 0,8 -M 1,0 -s 20 -zZq --thp 1 --no-data_rand_walk"

  perf: bench/numa.c:333: bind_to_cpumask: Assertion `!(ret)' failed.
<<>>

The Testcases uses CPU's 0 and 8. In function "parse_setup_cpu_list",
There is check to see if cpu number is greater than max cpu's possible
in the system ie via "if (bind_cpu_0 >= g->p.nr_cpus || bind_cpu_1 >=
g->p.nr_cpus) {".

But it could happen that system has say 48 CPU's, but only number of
online CPU's is 0-7. Other CPU's are offlined. Since "g->p.nr_cpus" is
48, so function will go ahead and set bit for CPU 8 also in cpumask (
td->bind_cpumask).

bind_to_cpumask function is called to set affinity using
sched_setaffinity and the cpumask. Since the CPU8 is not present, set
affinity will fail here with EINVAL.

Fix this issue by adding a check to make sure that, CPU's provided in
the input argument values are online before proceeding further and skip
the test. For this, include new helper function "is_cpu_online" in
"tools/perf/util/header.c".

Since "BIT(x)" definition will get included from header.h, remove
that from bench/numa.c

Reported-by: Disha Goel 
Signed-off-by: Athira Jajeev 
Tested-by: Disha Goel 
Cc: Ian Rogers 
Cc: Jiri Olsa 
Cc: Kajol Jain 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Nageswara R Sastry 
Cc: Srikar Dronamraju 
Cc: linuxppc-dev@lists.ozlabs.org
Link: https://lore.kernel.org/r/20220412164059.42654-2-atrajeev@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo

perf bench: Fix epoll bench to correct usage of affinity for machines with #CPUs > 1K

2022-04-09T15:34:29+00:00

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: Disha Goel 
Signed-off-by: Athira Jajeev 
Tested-by: Disha Goel 
Acked-by: Ian Rogers 
Cc: Jiri Olsa 
Cc: Kajol Jain 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Nageswara R Sastry 
Cc: Srikar Dronamraju 
Cc: linuxppc-dev@lists.ozlabs.org
Link: https://lore.kernel.org/r/20220406175113.87881-3-atrajeev@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo

perf bench: Fix futex bench to correct usage of affinity for machines with #CPUs > 1K

2022-04-09T15:34:29+00:00

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: Disha Goel 
Reviewed-by: Srikar Dronamraju 
Signed-off-by: Athira Jajeev 
Tested-by: Disha Goel 
Acked-by: Ian Rogers 
Cc: Jiri Olsa 
Cc: Kajol Jain 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Nageswara R Sastry 
Cc: linuxppc-dev@lists.ozlabs.org
Link: https://lore.kernel.org/r/20220406175113.87881-2-atrajeev@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo

perf evlist: Rename cpus to user_requested_cpus

2022-04-01T19:19:35+00:00

evlist contains cpus and all_cpus. all_cpus is the union of the cpu maps
of all evsels.

For non-task targets, cpus is set to be cpus requested from the command
line, defaulting to all online cpus if no cpus are specified.

For an uncore event, all_cpus may be just CPU 0 or every online CPU.

This causes all_cpus to have fewer values than the cpus variable which
is confusing given the 'all' in the name.

To try to make the behavior clearer, rename cpus to user_requested_cpus
and add comments on the two struct variables.

Signed-off-by: Ian Rogers 
Cc: Adrian Hunter 
Cc: Alexander Antonov 
Cc: Alexander Shishkin 
Cc: Alexei Starovoitov 
Cc: Alexey Bayduraev 
Cc: Andi Kleen 
Cc: Andrii Nakryiko 
Cc: Daniel Borkmann 
Cc: German Gomez 
Cc: James Clark 
Cc: Jiri Olsa 
Cc: John Fastabend 
Cc: John Garry 
Cc: KP Singh 
Cc: Kajol Jain 
Cc: Leo Yan 
Cc: Mark Rutland 
Cc: Martin KaFai Lau 
Cc: Mathieu Poirier 
Cc: Mike Leach 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Riccardo Mancini 
Cc: Song Liu 
Cc: Stephane Eranian 
Cc: Suzuki Poulouse 
Cc: Will Deacon 
Cc: Yonghong Song 
Cc: bpf@vger.kernel.org
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: netdev@vger.kernel.org
Link: http://lore.kernel.org/lkml/20220328232648.2127340-3-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo

perf bench: Fix NULL check against wrong variable

2022-03-12T13:49:13+00:00

We did a NULL check after "epollfdp = calloc(...)", but we checked
"epollfd" instead of "epollfdp".

Signed-off-by: Weiguo Li 
Acked-by: Davidlohr Bueso 
Cc: Alexander Shishkin 
Cc: Davidlohr Bueso 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Mark Rutland 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: https://lore.kernel.org/r/tencent_B5D64530EB9C7DBB8D2C88A0C790F1489D0A@qq.com
Signed-off-by: Arnaldo Carvalho de Melo

perf cpumap: Migrate to libperf cpumap api

2022-01-22T20:08:42+00:00

Switch from directly accessing the perf_cpu_map to using the appropriate
libperf API when possible. Using the API simplifies the job of
refactoring use of perf_cpu_map.

Signed-off-by: Ian Rogers 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Alexey Bayduraev 
Cc: Andi Kleen 
Cc: Andrew Morton 
Cc: André Almeida 
Cc: Andy Shevchenko 
Cc: Darren Hart 
Cc: Davidlohr Bueso 
Cc: Dmitriy Vyukov 
Cc: Eric Dumazet 
Cc: German Gomez 
Cc: James Clark 
Cc: Jin Yao 
Cc: Jiri Olsa 
Cc: John Garry 
Cc: Kajol Jain 
Cc: Kan Liang 
Cc: Leo Yan 
Cc: Madhavan Srinivasan 
Cc: Mark Rutland 
Cc: Masami Hiramatsu 
Cc: Miaoqian Lin 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Riccardo Mancini 
Cc: Shunsuke Nakamura 
Cc: Song Liu 
Cc: Stephane Eranian 
Cc: Stephen Brennan 
Cc: Steven Rostedt (VMware) 
Cc: Thomas Gleixner 
Cc: Thomas Richter 
Cc: Yury Norov 
Link: http://lore.kernel.org/lkml/20220122045811.3402706-3-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo

perf cpumap: Give CPUs their own type

2022-01-12T17:28:23+00:00

A common problem is confusing CPU map indices with the CPU, by wrapping
the CPU with a struct then this is avoided. This approach is similar to
atomic_t.

Committer notes:

To make it build with BUILD_BPF_SKEL=1 these files needed the
conversions to 'struct perf_cpu' usage:

  tools/perf/util/bpf_counter.c
  tools/perf/util/bpf_counter_cgroup.c
  tools/perf/util/bpf_ftrace.c

Also perf_env__get_cpu() was removed back in "perf cpumap: Switch
cpu_map__build_map to cpu function".

Additionally these needed to be fixed for the ARM builds to complete:

  tools/perf/arch/arm/util/cs-etm.c
  tools/perf/arch/arm64/util/pmu.c

Suggested-by: John Garry 
Signed-off-by: Ian Rogers 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Ingo Molnar 
Cc: James Clark 
Cc: Jiri Olsa 
Cc: Kajol Jain 
Cc: Kan Liang 
Cc: Leo Yan 
Cc: Mark Rutland 
Cc: Mathieu Poirier 
Cc: Mike Leach 
Cc: Namhyung Kim 
Cc: Paul Clarke 
Cc: Peter Zijlstra 
Cc: Riccardo Mancini 
Cc: Stephane Eranian 
Cc: Suzuki Poulouse 
Cc: Vineet Singh 
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: zhengjun.xing@intel.com
Link: https://lore.kernel.org/r/20220105061351.120843-49-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo