<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/tools/perf/bench/numa.c, branch linux-rolling-stable</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-rolling-stable</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-rolling-stable'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2024-11-16T19:36:47Z</updated>
<entry>
<title>perf header: Move is_cpu_online to numa bench</title>
<updated>2024-11-16T19:36:47Z</updated>
<author>
<name>Ian Rogers</name>
<email>irogers@google.com</email>
</author>
<published>2024-11-07T16:20:29Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c6fafe36bab32b9b24941fe381f0b66751021c25'/>
<id>urn:sha1:c6fafe36bab32b9b24941fe381f0b66751021c25</id>
<content type='text'>
The helper function is only used in the NUMA benchmark as typically
online CPUs are determined through perf_cpu_map__new_online_cpus().

Reduce the scope of the function for now.

Reviewed-by: James Clark &lt;james.clark@linaro.org&gt;
Signed-off-by: Ian Rogers &lt;irogers@google.com&gt;
Tested-by: Xu Yang &lt;xu.yang_2@nxp.com&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Albert Ou &lt;aou@eecs.berkeley.edu&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: Alexandre Ghiti &lt;alexghiti@rivosinc.com&gt;
Cc: Athira Rajeev &lt;atrajeev@linux.vnet.ibm.com&gt;
Cc: Ben Zong-You Xie &lt;ben717@andestech.com&gt;
Cc: Benjamin Gray &lt;bgray@linux.ibm.com&gt;
Cc: Bibo Mao &lt;maobibo@loongson.cn&gt;
Cc: Clément Le Goffic &lt;clement.legoffic@foss.st.com&gt;
Cc: Dima Kogan &lt;dima@secretsauce.net&gt;
Cc: Dr. David Alan Gilbert &lt;linux@treblig.org&gt;
Cc: Huacai Chen &lt;chenhuacai@kernel.org&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: John Garry &lt;john.g.garry@oracle.com&gt;
Cc: Kan Liang &lt;kan.liang@linux.intel.com&gt;
Cc: Leo Yan &lt;leo.yan@linux.dev&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Mike Leach &lt;mike.leach@linaro.org&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Palmer Dabbelt &lt;palmer@dabbelt.com&gt;
Cc: Paul Walmsley &lt;paul.walmsley@sifive.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Ravi Bangoria &lt;ravi.bangoria@amd.com&gt;
Cc: Sandipan Das &lt;sandipan.das@amd.com&gt;
Cc: Will Deacon &lt;will@kernel.org&gt;
Cc: Yicong Yang &lt;yangyicong@hisilicon.com&gt;
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-riscv@lists.infradead.org
Link: https://lore.kernel.org/r/20241107162035.52206-3-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf bench numa: Fix type of loop iterator in do_work, it should be 'long'</title>
<updated>2023-04-04T12:39:56Z</updated>
<author>
<name>Andreas Herrmann</name>
<email>aherrmann@suse.de</email>
</author>
<published>2023-03-30T07:42:02Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=337fa2db04785c60fc3aa736af98ce8358f87d34'/>
<id>urn:sha1:337fa2db04785c60fc3aa736af98ce8358f87d34</id>
<content type='text'>
'j' is of type int and start/end are of type 'long'. Thus 'j' might become
negative and cause segfault in access_data(). Fix it by using 'long' for
'j' as well.

Reviewed-by: James Clark &lt;james.clark@arm.com&gt;
Signed-off-by: Andreas Herrmann &lt;aherrmann@suse.de&gt;
Link: https://lore.kernel.org/r/20230330074202.14052-1-aherrmann@suse.de
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf tools: Make quiet mode consistent between tools</title>
<updated>2022-10-27T19:37:26Z</updated>
<author>
<name>James Clark</name>
<email>james.clark@arm.com</email>
</author>
<published>2022-10-18T09:41:36Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a527c2c1e2d43e9f145f5d0c5d6ac0bdf5220e22'/>
<id>urn:sha1:a527c2c1e2d43e9f145f5d0c5d6ac0bdf5220e22</id>
<content type='text'>
Use the global quiet variable everywhere so that all tools hide warnings
in quiet mode and update the documentation to reflect this.

'perf probe' claimed that errors are not printed in quiet mode but I
don't see this so remove it from the docs.

Signed-off-by: James Clark &lt;james.clark@arm.com&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: Ian Rogers &lt;irogers@google.com&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Link: https://lore.kernel.org/r/20221018094137.783081-3-james.clark@arm.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf bench: Update use of pthread mutex/cond</title>
<updated>2022-10-04T11:55:19Z</updated>
<author>
<name>Ian Rogers</name>
<email>irogers@google.com</email>
</author>
<published>2022-08-26T16:42:26Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a64d3af5d9eca3058ab6e0d3715ff36e4d6b5983'/>
<id>urn:sha1:a64d3af5d9eca3058ab6e0d3715ff36e4d6b5983</id>
<content type='text'>
Switch to the use of mutex wrappers that provide better error checking.

Signed-off-by: Ian Rogers &lt;irogers@google.com&gt;
Reviewed-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Acked-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: Alexandre Truong &lt;alexandre.truong@arm.com&gt;
Cc: Alexey Bayduraev &lt;alexey.v.bayduraev@linux.intel.com&gt;
Cc: Andi Kleen &lt;ak@linux.intel.com&gt;
Cc: Andres Freund &lt;andres@anarazel.de&gt;
Cc: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Cc: André Almeida &lt;andrealmeid@igalia.com&gt;
Cc: Athira Jajeev &lt;atrajeev@linux.vnet.ibm.com&gt;
Cc: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Cc: Colin Ian King &lt;colin.king@intel.com&gt;
Cc: Dario Petrillo &lt;dario.pk1@gmail.com&gt;
Cc: Darren Hart &lt;dvhart@infradead.org&gt;
Cc: Dave Marchevsky &lt;davemarchevsky@fb.com&gt;
Cc: Davidlohr Bueso &lt;dave@stgolabs.net&gt;
Cc: Fangrui Song &lt;maskray@google.com&gt;
Cc: Hewenliang &lt;hewenliang4@huawei.com&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: James Clark &lt;james.clark@arm.com&gt;
Cc: Jason Wang &lt;wangborong@cdjrlc.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Kajol Jain &lt;kjain@linux.ibm.com&gt;
Cc: Kim Phillips &lt;kim.phillips@amd.com&gt;
Cc: Leo Yan &lt;leo.yan@linaro.org&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Martin Liška &lt;mliska@suse.cz&gt;
Cc: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Nathan Chancellor &lt;nathan@kernel.org&gt;
Cc: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Cc: Pavithra Gurushankar &lt;gpavithrasha@gmail.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Quentin Monnet &lt;quentin@isovalent.com&gt;
Cc: Ravi Bangoria &lt;ravi.bangoria@amd.com&gt;
Cc: Remi Bernon &lt;rbernon@codeweavers.com&gt;
Cc: Riccardo Mancini &lt;rickyman7@gmail.com&gt;
Cc: Song Liu &lt;songliubraving@fb.com&gt;
Cc: Stephane Eranian &lt;eranian@google.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Thomas Richter &lt;tmricht@linux.ibm.com&gt;
Cc: Tom Rix &lt;trix@redhat.com&gt;
Cc: Weiguo Li &lt;liwg06@foxmail.com&gt;
Cc: Wenyu Liu &lt;liuwenyu7@huawei.com&gt;
Cc: William Cohen &lt;wcohen@redhat.com&gt;
Cc: Zechuan Chen &lt;chenzechuan1@huawei.com&gt;
Cc: bpf@vger.kernel.org
Cc: llvm@lists.linux.dev
Cc: yaowenbin &lt;yaowenbin1@huawei.com&gt;
Link: https://lore.kernel.org/r/20220826164242.43412-3-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf bench numa: Address compiler error on s390</title>
<updated>2022-05-21T17:45:19Z</updated>
<author>
<name>Thomas Richter</name>
<email>tmricht@linux.ibm.com</email>
</author>
<published>2022-05-20T08:11:58Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f8ac1c478424a9a14669b8cef7389b1e14e5229d'/>
<id>urn:sha1:f8ac1c478424a9a14669b8cef7389b1e14e5229d</id>
<content type='text'>
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 &gt; /dev/null 2&gt;&amp;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 &lt;namhyung@gmail.com&gt;
Signed-off-by: Thomas Richter &lt;tmricht@linux.ibm.com&gt;
Cc: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Cc: Sumanth Korikkar &lt;sumanthk@linux.ibm.com&gt;
Cc: Sven Schnelle &lt;svens@linux.ibm.com&gt;
Cc: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Link: https://lore.kernel.org/r/20220520081158.2990006-1-tmricht@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf bench: Fix two numa NDEBUG warnings</title>
<updated>2022-05-09T00:48:49Z</updated>
<author>
<name>Ian Rogers</name>
<email>irogers@google.com</email>
</author>
<published>2022-04-28T20:29:11Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=183d4f2d23acecb29695f4d07427c8594e3a9691'/>
<id>urn:sha1:183d4f2d23acecb29695f4d07427c8594e3a9691</id>
<content type='text'>
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 &lt;atrajeev@linux.vnet.ibm.com&gt;
Signed-off-by: Ian Rogers &lt;irogers@google.com&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: Andi Kleen &lt;ak@linux.intel.com&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: Jin Yao &lt;yao.jin@linux.intel.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Xing Zhengjun &lt;zhengjun.xing@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20220428202912.1056444-1-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf bench: Fix numa bench to fix usage of affinity for machines with #CPUs &gt; 1K</title>
<updated>2022-04-14T12:15:10Z</updated>
<author>
<name>Athira Rajeev</name>
<email>atrajeev@linux.vnet.ibm.com</email>
</author>
<published>2022-04-12T16:40:59Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f58faed7fb3f784efdbf3b401368dcf51a6e28fa'/>
<id>urn:sha1:f58faed7fb3f784efdbf3b401368dcf51a6e28fa</id>
<content type='text'>
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:

  &lt;&lt;&gt;&gt;
  perf: bench/numa.c:302: bind_to_node: Assertion `!(ret)' failed.
  Aborted (core dumped)
  &lt;&lt;&gt;&gt;

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 &lt;disgoel@linux.vnet.ibm.com&gt;
Signed-off-by: Athira Jajeev &lt;atrajeev@linux.vnet.ibm.com&gt;
Cc: Ian Rogers &lt;irogers@google.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Kajol Jain &lt;kjain@linux.ibm.com&gt;
Cc: Madhavan Srinivasan &lt;maddy@linux.vnet.ibm.com&gt;
Cc: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Cc: Nageswara R Sastry &lt;rnsastry@linux.ibm.com&gt;
Cc: Srikar Dronamraju &lt;srikar@linux.vnet.ibm.com&gt;
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 &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf bench: Fix numa testcase to check if CPU used to bind task is online</title>
<updated>2022-04-14T12:13:41Z</updated>
<author>
<name>Athira Rajeev</name>
<email>atrajeev@linux.vnet.ibm.com</email>
</author>
<published>2022-04-12T16:40:58Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8cb7a188ac33b71ec24a9081d1521f46dcab53c4'/>
<id>urn:sha1:8cb7a188ac33b71ec24a9081d1521f46dcab53c4</id>
<content type='text'>
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:

&lt;&lt;&gt;&gt;
  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.
&lt;&lt;&gt;&gt;

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 &gt;= g-&gt;p.nr_cpus || bind_cpu_1 &gt;=
g-&gt;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-&gt;p.nr_cpus" is
48, so function will go ahead and set bit for CPU 8 also in cpumask (
td-&gt;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 &lt;disgoel@linux.vnet.ibm.com&gt;
Signed-off-by: Athira Jajeev &lt;atrajeev@linux.vnet.ibm.com&gt;
Tested-by: Disha Goel &lt;disgoel@linux.vnet.ibm.com&gt;
Cc: Ian Rogers &lt;irogers@google.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Kajol Jain &lt;kjain@linux.ibm.com&gt;
Cc: Madhavan Srinivasan &lt;maddy@linux.vnet.ibm.com&gt;
Cc: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Cc: Nageswara R Sastry &lt;rnsastry@linux.ibm.com&gt;
Cc: Srikar Dronamraju &lt;srikar@linux.vnet.ibm.com&gt;
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 &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf tools: Fix various typos in comments</title>
<updated>2021-03-23T20:13:43Z</updated>
<author>
<name>Ingo Molnar</name>
<email>mingo@kernel.org</email>
</author>
<published>2021-03-23T16:09:15Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=4d39c89f0b94bf4a6e1ccf42702e7d80d210a5fd'/>
<id>urn:sha1:4d39c89f0b94bf4a6e1ccf42702e7d80d210a5fd</id>
<content type='text'>
Fix ~124 single-word typos and a few spelling errors in the perf tooling code,
accumulated over the years.

Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Link: https://lore.kernel.org/r/20210321113734.GA248990@gmail.com
Link: http://lore.kernel.org/lkml/20210323160915.GA61903@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf bench numa: Fix the condition checks for max number of NUMA nodes</title>
<updated>2021-03-06T19:54:25Z</updated>
<author>
<name>Athira Rajeev</name>
<email>atrajeev@linux.vnet.ibm.com</email>
</author>
<published>2021-02-25T16:50:02Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=394e4306b093d037bddcee7e1f0e8e6c53a558fc'/>
<id>urn:sha1:394e4306b093d037bddcee7e1f0e8e6c53a558fc</id>
<content type='text'>
In systems having higher node numbers available like node
255, perf numa bench will fail with SIGABORT.

  &lt;&lt;&gt;&gt;
  perf: bench/numa.c:1416: init: Assertion `!(g-&gt;p.nr_nodes &gt; 64 || g-&gt;p.nr_nodes &lt; 0)' failed.
  Aborted (core dumped)
  &lt;&lt;&gt;&gt;

Snippet from 'numactl -H' below on a powerpc system where the highest
node number available is 255:

  available: 6 nodes (0,8,252-255)
  node 0 cpus: &lt;cpu-list&gt;
  node 0 size: 519587 MB
  node 0 free: 516659 MB
  node 8 cpus: &lt;cpu-list&gt;
  node 8 size: 523607 MB
  node 8 free: 486757 MB
  node 252 cpus:
  node 252 size: 0 MB
  node 252 free: 0 MB
  node 253 cpus:
  node 253 size: 0 MB
  node 253 free: 0 MB
  node 254 cpus:
  node 254 size: 0 MB
  node 254 free: 0 MB
  node 255 cpus:
  node 255 size: 0 MB
  node 255 free: 0 MB
  node distances:
  node   0   8  252  253  254  255

Note: &lt;cpu-list&gt; expands to actual cpu list in the original output.
These nodes 252-255 are to represent the memory on GPUs and are valid
nodes.

The perf numa bench init code has a condition check to see if the number
of NUMA nodes (nr_nodes) exceeds MAX_NR_NODES. The value of MAX_NR_NODES
defined in perf code is 64. And the 'nr_nodes' is the value from
numa_max_node() which represents the highest node number available in the
system. In some systems where we could have NUMA node 255, this condition
check fails and results in SIGABORT.

The numa benchmark uses static value of MAX_NR_NODES in the code to
represent size of two NUMA node arrays and node bitmask used for setting
memory policy. Patch adds a fix to dynamically allocate size for the
two arrays and bitmask value based on the node numbers available in the
system. With the fix, perf numa benchmark will work with node configuration
on any system and thus removes the static MAX_NR_NODES value.

Signed-off-by: Athira Jajeev &lt;atrajeev@linux.vnet.ibm.com&gt;
Reviewed-by: Srikar Dronamraju &lt;srikar@linux.vnet.ibm.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Kajol Jain &lt;kjain@linux.ibm.com&gt;
Cc: Kan Liang &lt;kan.liang@linux.intel.com&gt;
Cc: Madhavan Srinivasan &lt;maddy@linux.ibm.com&gt;
Cc: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Ravi Bangoria &lt;ravi.bangoria@linux.ibm.com&gt;
Cc: linuxppc-dev@lists.ozlabs.org
Link: http://lore.kernel.org/lkml/1614271802-1503-1-git-send-email-atrajeev@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
</feed>
