qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]