| commit | ddf63df736257f9151d5e0fc3c6fddcb97f29cab | |
| author | Pavel Dovgalyuk <Pavel.Dovgaluk@gmail.com> | |
| Thu, 30 Apr 2020 09:13:49 +0000 (30 12:13 +0300) | ||
| committer | Paolo Bonzini <pbonzini@redhat.com> | |
| Wed, 10 Jun 2020 16:10:47 +0000 (10 12:10 -0400) | ||
| tree | 7228e6c60bb236ebfc859dc9e54fcf5329437cea | treesnapshot (tar.gz zip) |
| parent | 2356ff8500f3aec43070fcfa61a624ec36a8c6b4 | commitdiff |
replay: implement fair mutex
In record/replay icount mode main loop thread and vCPU thread
do not perform simultaneously. They take replay mutex to synchronize
the actions. Sometimes vCPU thread waits for locking the mutex for
very long time, because main loop releases the mutex and takes it
back again. Standard qemu mutex do not provide the ordering
capabilities.
This patch adds a "queue" for replay mutex. Therefore thread ordering
becomes more "fair". Threads are executed in the same order as
they are trying to take the mutex.
Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
Message-Id: <158823802979.28101.9340462887738957616.stgit@pasha-ThinkPad-X280>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In record/replay icount mode main loop thread and vCPU thread
do not perform simultaneously. They take replay mutex to synchronize
the actions. Sometimes vCPU thread waits for locking the mutex for
very long time, because main loop releases the mutex and takes it
back again. Standard qemu mutex do not provide the ordering
capabilities.
This patch adds a "queue" for replay mutex. Therefore thread ordering
becomes more "fair". Threads are executed in the same order as
they are trying to take the mutex.
Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
Message-Id: <158823802979.28101.9340462887738957616.stgit@pasha-ThinkPad-X280>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| replay/replay-internal.c | diffblobblamehistory |