aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/bench/futex-requeue.c
AgeCommit message (Collapse)AuthorFilesLines
2014-09-29perf bench futex: Sanitize -q option in requeueDavidlohr Bueso1-1/+3
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 <[email protected]> Cc: Davidlohr Bueso <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2014-09-29perf bench futex: Support operations for shared futexesDavidlohr Bueso1-9/+15
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 <[email protected]> Cc: Davidlohr Bueso <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2014-06-19perf bench futex: Use global --repeat optionDavidlohr Bueso1-9/+1
This option is available through perf-bench, use it instead and free the local option. Signed-off-by: Davidlohr Bueso <[email protected]> Cc: Aswin Chandramouleeswaran <[email protected]> Cc: Hitoshi Mitake <[email protected]> Cc: Jiri Olsa <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2014-03-14perf bench: Add futex-requeue microbenchmarkDavidlohr Bueso1-0/+211
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 <[email protected]> Acked-by: Darren Hart <[email protected]> Cc: Aswin Chandramouleeswaran <[email protected]> Cc: Darren Hart <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jason Low <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Scott J Norton <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Waiman Long <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>