1. 20 4月, 2017 2 次提交
  2. 27 3月, 2017 1 次提交
  3. 06 3月, 2017 1 次提交
  4. 15 2月, 2017 1 次提交
    • A
      perf bench numa: Make sure dprintf() is not defined · 6aa4d826
      Arnaldo Carvalho de Melo 提交于
      When building with clang we get this error:
      
        bench/numa.c:46:9: error: 'dprintf' macro redefined [-Werror,-Wmacro-redefined]
        #define dprintf(x...) do { if (g && g->p.show_details >= 1) printf(x); } while (0)
                ^
        /usr/include/bits/stdio2.h:145:12: note: previous definition is here
        #   define dprintf(fd, ...) \
                   ^
          CC       /tmp/build/perf/tests/parse-no-sample-id-all.o
        1 error generated.
      
      So, make sure it is undefined before using that name.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Davidlohr Bueso <dbueso@suse.de>
      Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
      Cc: Jakub Jelen <jjelen@redhat.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-f654o2svtrutamvxt7igwz74@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6aa4d826
  5. 10 2月, 2017 1 次提交
    • A
      perf bench numa: Avoid possible truncation when using snprintf() · 3aff8ba0
      Arnaldo Carvalho de Melo 提交于
      Addressing this warning from gcc 7:
      
          CC       /tmp/build/perf/bench/numa.o
        bench/numa.c: In function '__bench_numa':
        bench/numa.c:1582:42: error: '%d' directive output may be truncated writing between 1 and 10 bytes into a region of size between 8 and 17 [-Werror=format-truncation=]
             snprintf(tname, 32, "process%d:thread%d", p, t);
                                                  ^~
        bench/numa.c:1582:25: note: directive argument in the range [0, 2147483647]
             snprintf(tname, 32, "process%d:thread%d", p, t);
                                 ^~~~~~~~~~~~~~~~~~~~
        In file included from /usr/include/stdio.h:939:0,
                         from bench/../util/util.h:47,
                         from bench/../builtin.h:4,
                         from bench/numa.c:11:
        /usr/include/bits/stdio2.h:64:10: note: '__builtin___snprintf_chk' output between 17 and 35 bytes into a destination of size 32
           return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                __bos (__s), __fmt, __va_arg_pack ());
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        cc1: all warnings being treated as errors
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Petr Holasek <pholasek@redhat.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-twa37vsfqcie5gwpqwnjuuz9@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      3aff8ba0
  6. 24 8月, 2016 1 次提交
  7. 13 7月, 2016 1 次提交
  8. 22 3月, 2016 1 次提交
  9. 18 12月, 2015 1 次提交
  10. 20 10月, 2015 1 次提交
    • I
      perf bench: Harmonize all the -l/--nr_loops options · b0d22e52
      Ingo Molnar 提交于
      We have three benchmarking subsystems that specify some sort of 'number
      of loops' parameter - but all of them do it inconsistently:
      
       numa:              -l/--nr_loops
       sched messaging:   -l/--loops
       mem memset/memcpy: -i/--iterations
      
      Harmonize them to -l/--nr_loops by picking the numa variant - which is
      also the most likely one to have existing scripting which we don't want
      to break.
      
      Plus improve the parameter help texts to indicate the default value for
      the nr_loops variable to keep users from guessing ...
      
      Also propagate the naming to internal variables.
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1445241870-24854-13-git-send-email-mingo@kernel.org
      [ Let the harmonisation reach the perf-bench man page as well ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b0d22e52
  11. 18 5月, 2015 1 次提交
  12. 04 5月, 2015 1 次提交
  13. 28 4月, 2015 2 次提交
  14. 14 4月, 2014 1 次提交
  15. 14 3月, 2014 1 次提交
    • A
      perf bench numa: Make no args mean 'run all tests' · 0fae799e
      Arnaldo Carvalho de Melo 提交于
      If we call just:
      
        perf bench numa mem
      
      it will present the same output as:
      
        perf bench numa mem -h
      
      i.e. ask for instructions about what to run.
      
      While that is kinda ok, using 'run all tests' as the default, i.e.
      making 'no parms' be equivalent to:
      
        perf bench numa mem -a
      
      Will allow:
      
        perf bench numa all
      
      to actually do what is asked: i.e. run all the 'bench' tests, instead of
      responding to that by asking what to do.
      
      That, in turn, allows:
      
        perf bench all
      
      to actually complete, for the same reasons.
      
      And after that, the tests that come after that, and that at some point
      hit a NULL deref, will run, allowing me to reproduce a recently reported
      problem.
      
      That when you have the needed numa libraries, which wasn't the case for
      the reporter, making me a bit confused after trying to reproduce his
      report.
      
      So make no parms mean -a.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Patrick Palka <patrick@parcs.ath.cx>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-x7h0ghx4pef4n0brywg21krk@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0fae799e
  16. 01 11月, 2013 1 次提交
  17. 21 10月, 2013 1 次提交
  18. 11 10月, 2013 1 次提交
  19. 30 1月, 2013 1 次提交
    • I
      perf: Add 'perf bench numa mem' NUMA performance measurement suite · 1c13f3c9
      Ingo Molnar 提交于
      Add a suite of NUMA performance benchmarks.
      
      The goal was simulate the behavior and access patterns of real NUMA
      workloads, via a wide range of parameters, so this tool goes well
      beyond simple bzero() measurements that most NUMA micro-benchmarks use:
      
       - It processes the data and creates a chain of data dependencies,
         like a real workload would. Neither the compiler, nor the
         kernel (via KSM and other optimizations) nor the CPU can
         eliminate parts of the workload.
      
       - It randomizes the initial state and also randomizes the target
         addresses of the processing - it's not a simple forward scan
         of addresses.
      
       - It provides flexible options to set process, thread and memory
         relationship information: -G sets "global" memory shared between
         all test processes, -P sets "process" memory shared by all
         threads of a process and -T sets "thread" private memory.
      
       - There's a NUMA convergence monitoring and convergence latency
         measurement option via -c and -m.
      
       - Micro-sleeps and synchronization can be injected to provoke lock
         contention and scheduling, via the -u and -S options. This simulates
         IO and contention.
      
       - The -x option instructs the workload to 'perturb' itself artificially
         every N seconds, by moving to the first and last CPU of the system
         periodically. This way the stability of convergence equilibrium and
         the number of steps taken for the scheduler to reach equilibrium again
         can be measured.
      
       - The amount of work can be specified via the -l loop count, and/or
         via a -s seconds-timeout value.
      
       - CPU and node memory binding options, to test hard binding scenarios.
         THP can be turned on and off via madvise() calls.
      
       - Live reporting of convergence progress in an 'at glance' output format.
         Printing of convergence and deconvergence events.
      
      The 'perf bench numa mem -a' option will start an array of about 30
      individual tests that will each output such measurements:
      
       # Running  5x5-bw-thread, "perf bench numa mem -p 5 -t 5 -P 512 -s 20 -zZ0q --thp  1"
        5x5-bw-thread,                         20.276, secs,           runtime-max/thread
        5x5-bw-thread,                         20.004, secs,           runtime-min/thread
        5x5-bw-thread,                         20.155, secs,           runtime-avg/thread
        5x5-bw-thread,                          0.671, %,              spread-runtime/thread
        5x5-bw-thread,                         21.153, GB,             data/thread
        5x5-bw-thread,                        528.818, GB,             data-total
        5x5-bw-thread,                          0.959, nsecs,          runtime/byte/thread
        5x5-bw-thread,                          1.043, GB/sec,         thread-speed
        5x5-bw-thread,                         26.081, GB/sec,         total-speed
      
      See the help text and the code for more details.
      
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Hugh Dickins <hughd@google.com>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      1c13f3c9