Re: [Qemu-devel] [PATCH v2 0/3] Make thread pool implementation modular

[Paolo Bonzini <pbonzini@redhat.com>]

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