first say sorry for the same mail sent more than one time, I don't
know it will take so long time to come back.
hi, stefan:
thank for your explaining.
how about to remove kvm_handle_io/handle_mmio in kvm_run function
into kvm_main_loop, as these operation belong to io operation, this
will remove the qemu_mutux between the 2 threads. is this an
reasonable thought?
In order to keep the monitor to response to user quicker under
this suition, an easier way is to take monito io out of qemu_mutux
protection. this include vnc/serial/telnet io related with monitor,
as these io will not affect the running of vm itself, it need not in
so stirct protection.
Any suggestions? thanks.
Green.
2011/3/1 Stefan Hajnoczi <[email protected]>:
> On Tue, Mar 1, 2011 at 5:01 AM, ya su <[email protected]> wrote:
>> kvm start with disk image on nfs server, when nfs server can not be
>> reached, monitor will be blocked. I change io_thread to SCHED_RR
>> policy, it will work unfluently waiting for disk read/write timeout.
>
> There are some synchronous disk image reads that can put qemu-kvm to
> sleep until NFS responds or errors. For example, when starting
> hw/virtio-blk.c calls bdrv_guess_geometry() which may invoke
> bdrv_read().
>
> Once the VM is running and you're using virtio-blk then disk I/O
> should be asynchronous. There are some synchronous cases to do with
> migration, snapshotting, etc where we wait for outstanding aio
> requests. Again this can block qemu-kvm.
>
> So in short, there's no easy way to avoid blocking the VM in all cases
> today. You should find, however, that normal read/write operation to
> a running VM does not cause qemu-kvm to sleep.
>
> Stefan
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
