mirror of
https://github.com/Zenithsiz/ftmemsim-valgrind.git
synced 2026-02-03 18:13:01 +00:00
d7ccda99e6
and scheduler lock (pipe based or futex based) See http://www.valgrind.org/docs/manual/manual-core.html#manual-core.pthreads_perf_sched for background info about cpu freq scaling and valgrind thread scheduler. To reproduce the interaction, do: for sched in --fair-sched=yes --fair-sched=no do for affinity in 0 1 do echo $sched $affinity time ./vg-in-place $sched -q ./gdbserver_tests/sleepers 1000000 0 1000 B-B-B-B- $affinity done done which gives the below output (intel core i5-6402P, debian 8, kernel 3.16.0). In summary: the fair scheduler is fair, the pipe based scheduler can be really unfair (e.g. with --fair-sched=no and no affinity, 2 threads are finishing their work, while the 2 other threads are starting their work only after the first 2 have fully finished). The difference in timing is significant : 1m14s versus around 47 seconds. Note: If the governor is set to performance, strangely, the time needed for --fair-sched=no increases slighltly (to around 48 seconds). The time for --fair-sched=yes with or without affinity is then also to around 48 seconds. Below is timing with on-demand governor: --fair-sched=yes 0 loops/sleep_ms/burn/threads_spec/affinity: 1000000 0 1000 B-B-B-B- 0 Brussels ready to sleep and/or burn London ready to sleep and/or burn Petaouchnok ready to sleep and/or burn main ready to sleep and/or burn Brussels finished to sleep and/or burn London finished to sleep and/or burn Petaouchnok finished to sleep and/or burn main finished to sleep and/or burn real 1m14.582s user 1m14.348s sys 0m0.204s --fair-sched=yes 1 loops/sleep_ms/burn/threads_spec/affinity: 1000000 0 1000 B-B-B-B- 1 Brussels ready to sleep and/or burn London ready to sleep and/or burn Petaouchnok ready to sleep and/or burn main ready to sleep and/or burn main finished to sleep and/or burn Brussels finished to sleep and/or burn Petaouchnok finished to sleep and/or burn London finished to sleep and/or burn real 0m46.785s user 0m46.756s sys 0m0.032s --fair-sched=no 0 loops/sleep_ms/burn/threads_spec/affinity: 1000000 0 1000 B-B-B-B- 0 Brussels ready to sleep and/or burn Brussels finished to sleep and/or burn London ready to sleep and/or burn London finished to sleep and/or burn Petaouchnok ready to sleep and/or burn main ready to sleep and/or burn Petaouchnok finished to sleep and/or burn main finished to sleep and/or burn real 0m47.742s user 0m48.224s sys 0m0.084s --fair-sched=no 1 loops/sleep_ms/burn/threads_spec/affinity: 1000000 0 1000 B-B-B-B- 1 Brussels ready to sleep and/or burn London ready to sleep and/or burn Petaouchnok ready to sleep and/or burn main ready to sleep and/or burn Brussels finished to sleep and/or burn London finished to sleep and/or burn main finished to sleep and/or burn Petaouchnok finished to sleep and/or burn real 0m46.601s user 0m46.568s sys 0m0.036s git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16251
15 lines
729 B
Plaintext
15 lines
729 B
Plaintext
# test that vgdb can invoke a process when all threads are in Runnable or Yielding mode
|
|
# If the test goes wrong, it might consume CPU during a long time.
|
|
prog: sleepers
|
|
args: 1 0 1000000000 B-B-B-B- 1
|
|
vgopts: --tool=memcheck --vgdb=yes --vgdb-prefix=./vgdb-prefix-mcinvokeRU
|
|
stderr_filter: filter_make_empty
|
|
# as the Valgrind process is always busy, we do not need the vgdb.invoker prereq.
|
|
# We even disable invoker to avoid spurious attach error message
|
|
# on kernels where ptrace is restricted.
|
|
progB: invoker
|
|
argsB: 10 --vgdb-prefix=./vgdb-prefix-mcinvokeRU --max-invoke-ms=0 --wait=60 -c v.wait 0
|
|
# if the --wait is not enough, the test will fail or block.
|
|
stdoutB_filter: filter_memcheck_monitor
|
|
stderrB_filter: filter_vgdb
|