Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 15 2月, 2017 1 次提交
    • A
      Revert "perf bench futex: Sanitize numeric parameters" · 16cab322
      由 Arnaldo Carvalho de Melo 提交于 
      This reverts commit 60758d66.

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 <options>

      -t, --threads <n>     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 <options>

      -t, --threads <n>     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 <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Davidlohr Bueso <dbueso@suse.de>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-2kl68v22or31vw643m2exz8x@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      16cab322
  3. 25 10月, 2016 1 次提交
  5. 24 8月, 2016 1 次提交
  7. 13 7月, 2016 3 次提交
  9. 18 12月, 2015 1 次提交
  11. 09 5月, 2015 1 次提交
    • D
      perf bench futex: Support parallel waker threads · d65817b4
      由 Davidlohr Bueso 提交于 
      The futex-wake benchmark only measures wakeups done within a single
process. While this has value in its own, it does not really generate
any hb->lock contention.

A new benchmark 'wake-parallel' is added, by extending the futex-wake
code such that we can measure parallel waker threads. The program output
shows the avg per-thread latency in order to complete its share of
wakeups:

Run summary [PID 13474]: blocking on 512 threads (at [private] futex 0xa88668), 8 threads waking up 64 at a time.

[Run 1]: Avg per-thread latency (waking 64/512 threads) in 0.6230 ms (+-15.31%)
[Run 2]: Avg per-thread latency (waking 64/512 threads) in 0.5175 ms (+-29.95%)
[Run 3]: Avg per-thread latency (waking 64/512 threads) in 0.7578 ms (+-18.03%)
[Run 4]: Avg per-thread latency (waking 64/512 threads) in 0.8944 ms (+-12.54%)
[Run 5]: Avg per-thread latency (waking 64/512 threads) in 1.1204 ms (+-23.85%)
Avg per-thread latency (waking 64/512 threads) in 0.7826 ms (+-9.91%)

Naturally, different combinations of numbers of blocking and waker
threads will exhibit different information.
Signed-off-by: NDavidlohr Bueso <dbueso@suse.de>
Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Cc: Davidlohr Bueso <dbueso@suse.de>
Link: http://lkml.kernel.org/r/1431110280-20231-1-git-send-email-dave@stgolabs.netSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d65817b4