27 Mar, 2017

1 commit

  • We got it from the git sources but never used it for anything, with the
    place where this would be somehow used remaining:

    static int run_builtin(struct cmd_struct *p, int argc, const char **argv)
    {
    prefix = NULL;
    if (p->option & RUN_SETUP)
    prefix = NULL; /* setup_perf_directory(); */

    Ditch it.

    Cc: Adrian Hunter
    Cc: David Ahern
    Cc: Jiri Olsa
    Cc: Namhyung Kim
    Cc: Wang Nan
    Link: http://lkml.kernel.org/n/tip-uw5swz05vol0qpr32c5lpvus@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo

    Arnaldo Carvalho de Melo
     

04 Mar, 2017

1 commit

  • When building with clang on a musl libc system, Alpine Linux, we end up
    hitting a problem where memset() is used but its prototype is not
    present, add it to avoid this:

    bench/futex-wake.c:99:3: error: implicitly declaring library function 'memset' with type 'void *(void *, int, unsigned long)'
    [-Werror,-Wimplicit-function-declaration]
    CPU_ZERO(&cpu);
    ^
    /usr/include/sched.h:127:23: note: expanded from macro 'CPU_ZERO'
    #define CPU_ZERO(set) CPU_ZERO_S(sizeof(cpu_set_t),set)
    ^
    /usr/include/sched.h:110:30: note: expanded from macro 'CPU_ZERO_S'
    #define CPU_ZERO_S(size,set) memset(set,0,size)
    ^
    bench/futex-wake.c:99:3: note: include the header or explicitly provide a declaration for 'memset'

    Found while updating my test build containers to build perf with clang in more
    systems.

    Cc: Adrian Hunter
    Cc: David Ahern
    Cc: Davidlohr Bueso
    Cc: Jiri Olsa
    Cc: Namhyung Kim
    Cc: Wang Nan
    Link: http://lkml.kernel.org/n/tip-jh10vaz2r98zl6gm5iau8prr@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo

    Arnaldo Carvalho de Melo
     

15 Feb, 2017

1 commit

  • This reverts commit 60758d6668b3e2fa8e5fd143d24d0425203d007e.

    Now that libsubcmd makes sure that OPT_UINTEGER options will not
    return negative values, we can revert this patch while addressing
    the problem it solved:

    # perf bench futex hash -t -4
    # Running 'futex/hash' benchmark:
    Error: switch `t' expects an unsigned numerical value
    Usage: perf bench futex hash

    -t, --threads Specify amount of threads
    # perf bench futex hash -t-4
    # Running 'futex/hash' benchmark:
    Error: switch `t' expects an unsigned numerical value
    Usage: perf bench futex hash

    -t, --threads Specify amount of threads
    #

    IMO it is more reasonable to flat out refuse to process a negative
    number than to silently turn it into an absolute value.

    This also helps in silencing clang's complaint about asking for an
    absolute value of an unsigned integer:

    bench/futex-hash.c:133:10: error: taking the absolute value of unsigned type 'unsigned int' has no effect [-Werror,-Wabsolute-value]
    nsecs = futexbench_sanitize_numeric(nsecs);
    ^
    bench/futex.h:104:42: note: expanded from macro 'futexbench_sanitize_numeric'
    #define futexbench_sanitize_numeric(__n) abs((__n))
    ^
    bench/futex-hash.c:133:10: note: remove the call to 'abs' since unsigned values cannot be negative

    Cc: Adrian Hunter
    Cc: David Ahern
    Cc: Davidlohr Bueso
    Cc: Jiri Olsa
    Cc: Josh Poimboeuf
    Cc: Namhyung Kim
    Cc: Wang Nan
    Link: http://lkml.kernel.org/n/tip-2kl68v22or31vw643m2exz8x@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo

    Arnaldo Carvalho de Melo
     

25 Oct, 2016

1 commit

  • This gets rid of oddities such as:

    perf bench futex hash -t -4
    perf: calloc: Cannot allocate memory

    Runtime (and many more) are equally busted, i.e. run for bogus amounts of
    time. Just use the abs, instead of, for example errorring out.

    Committer note:

    After the patch:

    $ perf bench futex hash -t -4
    # Running 'futex/hash' benchmark:
    Run summary [PID 10178]: 4 threads, each operating on 1024 [private] futexes for 10 secs.

    [thread 0] futexes: 0x34f9fa0 ... 0x34faf9c [ 4702208 ops/sec ]
    [thread 1] futexes: 0x34fb140 ... 0x34fc13c [ 4707020 ops/sec ]
    [thread 2] futexes: 0x34fc2e0 ... 0x34fd2dc [ 4711526 ops/sec ]
    [thread 3] futexes: 0x34fd480 ... 0x34fe47c [ 4709683 ops/sec ]

    Averaged 4707609 operations/sec (+- 0.04%), total secs = 10
    $

    Signed-off-by: Davidlohr Bueso
    Tested-by: Arnaldo Carvalho de Melo
    Link: http://lkml.kernel.org/r/1477342613-9938-3-git-send-email-dave@stgolabs.net
    Signed-off-by: Arnaldo Carvalho de Melo

    Davidlohr Bueso
     

24 Aug, 2016

1 commit


13 Jul, 2016

3 commits


18 Dec, 2015

1 commit

  • Move the subcommand-related files from perf to a new library named
    libsubcmd.a.

    Since we're moving files anyway, go ahead and rename 'exec_cmd.*' to
    'exec-cmd.*' to be consistent with the naming of all the other files.

    Signed-off-by: Josh Poimboeuf
    Cc: Jiri Olsa
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Link: http://lkml.kernel.org/r/c0a838d4c878ab17fee50998811612b2281355c1.1450193761.git.jpoimboe@redhat.com
    Signed-off-by: Arnaldo Carvalho de Melo

    Josh Poimboeuf
     

28 Apr, 2015

1 commit

  • The futex-requeue benchmark can hang because of missing wakeups once the
    benchmark is done, ie:

    [Run 1]: Requeued 1024 of 1024 threads in 0.3290 ms
    perf: couldn't wakeup all tasks (135/1024)

    This bug, while perhaps suggesting missing wakeups in kernel futex code,
    is merely a consequence of the crappy FUTEX_CMP_REQUEUE man page,
    incorrectly mentioning that the number of requeued tasks is in fact
    returned, not the wakeups.

    This patch acknowledges this and updates the corresponding futex_wake
    code around it.

    Signed-off-by: Davidlohr Bueso
    Cc: Mel Gorman
    Link: http://lkml.kernel.org/r/1429894848.10273.44.camel@stgolabs.net
    Signed-off-by: Arnaldo Carvalho de Melo

    Davidlohr Bueso
     

30 Sep, 2014

2 commits

  • When given the number of threads to requeue at once by user input,
    there's always the risk of this value being larger than the total number
    of threads. This doesn't make any sense, and the kernel can easily deal
    with such sort of situations, hence no big deal. We should however
    prevent bogus output such as:

    ./perf bench --repeat 2 futex requeue -q 10
    Run summary [PID 22210]: Requeuing 4 threads (from [private] 0x99ef3c to 0x99ef38), 10 at a time.

    [Run 1]: Requeued 10 of 4 threads in 0.0040 ms
    [Run 2]: Requeued 10 of 4 threads in 0.0030 ms
    Requeued 10 of 4 threads in 0.0035 ms (+-14.29%)

    Signed-off-by: Davidlohr Bueso
    Cc: Davidlohr Bueso
    Link: http://lkml.kernel.org/r/1412008868-22328-2-git-send-email-dave@stgolabs.net
    Signed-off-by: Arnaldo Carvalho de Melo

    Davidlohr Bueso
     
  • Unlike futex-hash, requeuing and wakeup benchmarks do not support shared
    futexes, limiting the usefulness of the programs. Correct this, and
    allow using the local -S parameter. The default remains using private
    futexes.

    Signed-off-by: Davidlohr Bueso
    Cc: Davidlohr Bueso
    Link: http://lkml.kernel.org/r/1412008868-22328-1-git-send-email-dave@stgolabs.net
    Signed-off-by: Arnaldo Carvalho de Melo

    Davidlohr Bueso
     

20 Jun, 2014

1 commit

  • This option is available through perf-bench, use it instead and free the
    local option.

    Signed-off-by: Davidlohr Bueso
    Cc: Aswin Chandramouleeswaran
    Cc: Hitoshi Mitake
    Cc: Jiri Olsa
    Link: http://lkml.kernel.org/r/1402942467-10671-6-git-send-email-davidlohr@hp.com
    Signed-off-by: Arnaldo Carvalho de Melo

    Davidlohr Bueso
     

14 Mar, 2014

1 commit

  • Block a bunch of threads on a futex and requeue them on another, N at a
    time.

    This program is particularly useful to measure the latency of nthread
    requeues without waking up any tasks -- thus mimicking a regular
    futex_wait.

    An example run:

    $ perf bench futex requeue -r 100 -t 64
    Run summary [PID 151011]: Requeuing 64 threads (from 0x7d15c4 to 0x7d15c8), 1 at a time.

    [Run 1]: Requeued 64 of 64 threads in 0.0400 ms
    [Run 2]: Requeued 64 of 64 threads in 0.0390 ms
    [Run 3]: Requeued 64 of 64 threads in 0.0400 ms
    ...
    [Run 100]: Requeued 64 of 64 threads in 0.0390 ms
    Requeued 64 of 64 threads in 0.0399 ms (+-0.37%)

    Signed-off-by: Davidlohr Bueso
    Acked-by: Darren Hart
    Cc: Aswin Chandramouleeswaran
    Cc: Darren Hart
    Cc: Ingo Molnar
    Cc: Jason Low
    Cc: Peter Zijlstra
    Cc: Scott J Norton
    Cc: Thomas Gleixner
    Cc: Waiman Long
    Link: http://lkml.kernel.org/r/1387081917-9102-4-git-send-email-davidlohr@hp.com
    Signed-off-by: Arnaldo Carvalho de Melo

    Davidlohr Bueso