diff options
| author | Anthony Liguori <aliguori@us.ibm.com> | 2013-04-05 08:46:00 -0500 |
|---|---|---|
| committer | Anthony Liguori <aliguori@us.ibm.com> | 2013-04-05 12:53:33 -0500 |
| commit | 893986fe94eb229f2317f50fac0e35e068eb66ba (patch) | |
| tree | 2fb99f66ab6e99e632980a96cdfee3e9d21d0067 /hw/sd.c | |
| parent | d185c094b404b4ff392b77d1244c0233da7d53bd (diff) | |
| download | qemu-893986fe94eb229f2317f50fac0e35e068eb66ba.zip qemu-893986fe94eb229f2317f50fac0e35e068eb66ba.tar.gz qemu-893986fe94eb229f2317f50fac0e35e068eb66ba.tar.bz2 | |
main-loop: drop the BQL if the I/O appears to be spinning
The char-flow refactoring introduced a busy-wait that depended on
an action from the VCPU thread. However, the VCPU thread could
never take that action because the busy-wait starved the VCPU thread
of the BQL because it never dropped the mutex while running select.
Paolo doesn't want to drop this optimization for fear that we will
stop detecting these busy waits. I'm afraid to keep this optimization
even with the busy-wait fixed because I think a similar problem can
occur just with heavy I/O thread load manifesting itself as VCPU pauses.
As a compromise, introduce an artificial timeout after a thousand
iterations but print a rate limited warning when this happens. This
let's us still detect when this condition occurs without it being
a fatal error.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1365169560-11012-1-git-send-email-aliguori@us.ibm.com
Diffstat (limited to 'hw/sd.c')
0 files changed, 0 insertions, 0 deletions