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
16 lines
660 B
Plaintext
16 lines
660 B
Plaintext
# Tests the case when gdb sends a character to gdbserver while
|
|
# the gdbserver was forced invoked just before.
|
|
# gdbserver must send a signal to itself that is wait-ed for by vgdb.
|
|
# But if this signal is masked, then vgdb does not recuperate the control
|
|
# and Valgrind dies. See function give_control_back_to_vgdb in m_gdbserver.c
|
|
prog: sleepers
|
|
args: 1 10000000 0 -S-S-S-S 1
|
|
vgopts: --tool=none --vgdb=yes --vgdb-error=0 --vgdb-prefix=./vgdb-prefix-nlsigvgdb
|
|
stderr_filter: filter_stderr
|
|
prereq: test -e gdb -a -f vgdb.invoker
|
|
progB: gdb
|
|
argsB: --quiet -l 60 --nx ./sleepers
|
|
stdinB: nlsigvgdb.stdinB.gdb
|
|
stdoutB_filter: filter_gdb
|
|
stderrB_filter: filter_gdb
|