diff options
author | kfraser@localhost.localdomain <kfraser@localhost.localdomain> | 2007-05-31 10:30:15 +0100 |
---|---|---|
committer | kfraser@localhost.localdomain <kfraser@localhost.localdomain> | 2007-05-31 10:30:15 +0100 |
commit | ced5801d8bd6b3d2b267de5bee64441e9378828a (patch) | |
tree | cab659a5e5bb8ad6a075860be2e24774e60ffddc /linux-2.6-xen-sparse/arch/i386/kernel/init_task-xen.c | |
parent | f5e0354c5306bd16625e8ca5f612ce3d5fc0d59a (diff) | |
download | xen-ced5801d8bd6b3d2b267de5bee64441e9378828a.tar.gz xen-ced5801d8bd6b3d2b267de5bee64441e9378828a.tar.bz2 xen-ced5801d8bd6b3d2b267de5bee64441e9378828a.zip |
Fix the very-slow-IDE-IO-speed issue of Qemu 0.90
c/s 15021 updated Qemu to 0.90. In the new Qemu's ide.c, asynchronous
IO (AIO) is used to replace the previous DMA thread; here when an AIO
request is completed, dom0 sends a signal SIGUSR2 to Qemu (see
block-raw.c: qemu_aio_init(),raw_aio_setup()), then the signal
interrupts the select() in main_loop_wait() at once, next,
qemu_aio_poll() is called to reap a completed AIO request.
However, in certain Linux distributions (i.e., x86_64 RHEL 4u4), if
Qemu is spawned by the python script image.py of Control Panel, the
SIGUSR2 of Qemu is blocked by default due to some reasons (i.e. it
seems Python 2.3.4 has this issue; 2.4.2 is ok); so in most cases the
select() in main_loop_wait() can only time out in 10ms, then the
qemu_aio_poll() is called - this results in a very slow disk IO
speed...
This patch ensures aio_sig_num is unblocked when the AIO is used in
Qemu 0.90.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Diffstat (limited to 'linux-2.6-xen-sparse/arch/i386/kernel/init_task-xen.c')
0 files changed, 0 insertions, 0 deletions