[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] qcow2: Order concurrent AIO requests on the sam
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH] qcow2: Order concurrent AIO requests on the same unallocated cluster |
Date: |
Tue, 01 Sep 2009 12:50:12 +0200 |
User-agent: |
Thunderbird 2.0.0.23 (X11/20090825) |
Avi Kivity schrieb:
> On 08/31/2009 05:48 PM, Kevin Wolf wrote:
>> When two AIO requests write to the same cluster, and this cluster is
>> unallocated, currently both requests allocate a new cluster and the second
>> one
>> merges the first one when it is completed. This means an cluster allocation,
>> a
>> read and a cluster deallocation which cause some overhead. If we simply let
>> the
>> second request wait until the first one is done, we improve overall
>> performance
>> with AIO requests (specifially, qcow2/virtio combinations).
>>
>> This patch maintains a list of in-flight requests that have allocated new
>> clusters. A second request touching the same cluster is limited so that it
>> either doesn't touch the allocation of the first request (so it can have a
>> non-overlapping allocation) or it waits for the first request to complete.
>>
>
> Can't this cause an even/odd pattern where all even-numbered requests
> run first, then all the odd-numbered requests?
>
> (0 goes to disk, 1 depends on it, 2 depends on 1, which isn't allocating
> now, so it goes to disk, 3 depends on 2, ...)
I guess it can happen in theory, not sure if it matters in practice. You
are worried about image fragmentation? I think we could do something
about it with a cleverer cluster allocation.
However, I don't think it's an argument against this patch. What
currently happens isn't much better: Allocate n clusters, free n-1.
Almost as good in producing fragmentation.
> Do you have performance numbers?
No really detailed numbers. Installation time for RHEL on qcow2/virtio
went down from 34 min to 19 min, though.
Kevin