Il 11/11/2013 19:32, Alex Bligh ha scritto: > > On 11 Nov 2013, at 18:01, Paolo Bonzini wrote: > >> Il 11/11/2013 18:59, Alex Bligh ha scritto: >>>> Why is it necessary to push this task down into the host? I don't >>>> understand the advantage of this approach except that maybe it works >>>> around certain misconfigurations, I/O scheduler quirks, or plain old >>>> bugs - all of which should be investigated and fixed at the source >>>> instead of adding another layer of code to mask them. >>> >>> I can see an argument why a guest with two very differently >>> performing disks attached might be best served by two worker >>> threads, particularly if one such thread was in part CPU bound >>> (inventing this use case is left as an exercise for the reader). >> >> In most cases you want to use aio=native anyway, and then the QEMU >> thread pool is entirely bypassed. > > 'most cases' - really? I thought anything using either qcow2 or > ceph won't support that?
qcow2 works very well with aio=native. ceph, libiscsi, gluster, etc. will not support aio=native indeed, but then they won't use the thread pool either so I wasn't thinking about them (only files and block devices). Paolo