[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 0/3] Make thread pool implementation modular
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH v2 0/3] Make thread pool implementation modular |
Date: |
Mon, 11 Nov 2013 19:44:33 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9 |
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
- Re: [Qemu-devel] [PATCH v2 1/3] Make thread pool implementation modular, (continued)