[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [RFC PATCH 00/40] Sneak peek of virtio and
From: |
Christian Borntraeger |
Subject: |
Re: [Qemu-block] [Qemu-devel] [RFC PATCH 00/40] Sneak peek of virtio and dataplane changes for 2.6 |
Date: |
Thu, 26 Nov 2015 10:41:42 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 |
On 11/26/2015 10:36 AM, Christian Borntraeger wrote:
> On 11/24/2015 07:00 PM, Paolo Bonzini wrote:
>> This large series is basically all that I would like to get into 2.6.
>> It is a combination of several pieces of work on dataplane and
>> multithreaded block layer.
>>
>> It's also a large part of why I would like someone else to look at
>> miscellaneous patches for a while (in case you've missed that). I
>> can foresee that following the reviews is going to be a huge time drain.
>>
>> With it I can get ~1300 Kiops on 8 disks (which I achieve with 2 iothreads
>> and 5 VCPUs). The bulk of the improvement actually comes from the first
>> 8 patches, but the rest of the series is what prepares for what's next
>> to come in QEMU 2.7 and later, such as a multiqueue block layer.
>>
>> It's tedious to review, with some pretty large patches (3, 32, 33, 35).
> On 11/24/2015 07:00 PM, Paolo Bonzini wrote:
>> This large series is basically all that I would like to get into 2.6.
>> It is a combination of several pieces of work on dataplane and
>> multithreaded block layer.
>>
>> It's also a large part of why I would like someone else to look at
>> miscellaneous patches for a while (in case you've missed that). I
>> can foresee that following the reviews is going to be a huge time drain.
>>
>> With it I can get ~1300 Kiops on 8 disks (which I achieve with 2 iothreads
>> and 5 VCPUs). The bulk of the improvement actually comes from the first
>> 8 patches, but the rest of the series is what prepares for what's next
>> to come in QEMU 2.7 and later, such as a multiqueue block layer.
>
> For some unknown reason, this seems to be slightly slower than 2.5-rc1 on my
> old z196. (have not net tested the z13)
>
> your branch is certainly better regarding malloc, but worse regarding others.
Using the first 8 patches or so (commit be2f6b163e2b2a604f52a258fd932142c5974ffe
vring: slim down allocation of VirtQueueElements)
is slightly faster than 2.5.0-rc1, so the regression seems to come from some
of the later patches.
- [Qemu-block] [PATCH 34/40] block: explicitly acquire aiocontext in timers that need it, (continued)
- [Qemu-block] [PATCH 34/40] block: explicitly acquire aiocontext in timers that need it, Paolo Bonzini, 2015/11/24
- [Qemu-block] [PATCH 33/40] block: explicitly acquire aiocontext in bottom halves that need it, Paolo Bonzini, 2015/11/24
- [Qemu-block] [PATCH 32/40] block: explicitly acquire aiocontext in callbacks that need it, Paolo Bonzini, 2015/11/24
- [Qemu-block] [PATCH 37/40] async: optimize aio_bh_poll, Paolo Bonzini, 2015/11/24
- [Qemu-block] [PATCH 36/40] aio: update locking documentation, Paolo Bonzini, 2015/11/24
- [Qemu-block] [PATCH 35/40] block: explicitly acquire aiocontext in aio callbacks that need it, Paolo Bonzini, 2015/11/24
- [Qemu-block] [PATCH 38/40] aio-posix: partially inline aio_dispatch into aio_poll, Paolo Bonzini, 2015/11/24
- [Qemu-block] [PATCH 40/40] dma-helpers: avoid lock inversion with AioContext, Paolo Bonzini, 2015/11/24
- [Qemu-block] [PATCH 39/40] async: remove unnecessary inc/dec pairs, Paolo Bonzini, 2015/11/24
- Re: [Qemu-block] [Qemu-devel] [RFC PATCH 00/40] Sneak peek of virtio and dataplane changes for 2.6, Christian Borntraeger, 2015/11/26