[Qemu-discuss] qcow2 performance improve

[yang.bin18]

> > Hi,> > > > When use cluster_size=1M qcow2 newly created to test "32k rand 
> > write" in the> > VM,We get low performance within VM。But there are huge 
> > “write” requests in HOST> > which falls into qemu stack of"perform_cow".> 
> > These sorts of questions are better asked on list, so that they are > 
> > archived and available to anyone interested, rather than limiting it to > 
> > just the scattershot group of individual developers that you picked.> > > > 
> > > >   We found three scene to use cow.> > > >   1. write cluster have 
> > snapshot> Yes, if you write to a cluster with a refcount > 1 (because of an 
> > > internal snapshot), you must COW the portion of the cluster not touched > 
> > by the write when allocating the new cluster.>>  >>   2. write img has 
> > backing file> Yes, if you write a new cluster that previously read from the 
> > backing > file, you must COW the portion of the cluster not touched by the 
> > write.> In both of these cases, since you are doing random 32k writes, but 
> > with > a cluster size of 1M, the code indeed has to read 1M from the 
> > original > source (well, it can get away with 1M-32k, but syscall-wise it's 
> > more > efficient to read the entire thing than to worry about avoiding the 
> > read > of 3% of the buffer), then splice in the 32k being touched, then 
> > write > 1M to the destination.  So yes, you are getting larger host 
> > operations > due to COW.> Also, there has been talk on list about the 
> > possibility of a > non-backwards-compatible change to the qcow2 spec to 
> > allow partial > cluster allocation, where you would not have to COW so much 
> > data at the > time of the first write to a cluster. That will definitely 
> > have > performance improvements for the scenario you describe, at the 
> > expense > of requiring new tools that understand the new feature bit.> > > 
> > >   3. two concurrent writes happen to the same unallocated> > cluster.Each 
> > write allocates separate cluster and writes data concurrently 。> If there 
> > is no backing file and no shared refcount, then ultimately both > writes 
> > must end up in the same final cluster. COW shouldn't be > necessary, as 
> > long as the code is careful that the two operations don't > allocate two 
> > separate clusters.> > > >   For scene 2 and 3，we want to check the 
> > necessity before cow.> > > >   For scene 2 ,to check bs->backing,if false 
> > ,not cow .> > > >   For scene 3,if not concurrent writes happen to the 
> > same> > unallocated cluster,not cow.> I'm not sure what your actual 
> > question is. If you have a stack trace or > performance trace for an 
> > example reproducer that highlights a hotspot in > the code that you are 
> > trying to optimize, that would go a long way. But > as I said before, 
> > please send it to the list.> -- > Eric Blake, Principal Software Engineer> 
> > Red Hat, Inc.           +1-919-301-3266> Virtualization:  qemu.org | 
> > libvirt.org






       Our question is "When use cluster_size=1M qcow2 newly created which has 
not backing to test "32k rand write" in theVM,We get low performance within VM".


       And the hotspot is in "qcow2_alloc_cluster_link_l2->perform_cow"。For 
scene 2 ,we want to add "check bs->backing",if false ,not cow to improve 
performance.


   


>Hi!>first of all, perhaps you may want to post this question to one of 
>the>QEMU mailing 
>lists:>https://lists.nongnu.org/mailman/listinfo/qemu-discuss>https://lists.nongnu.org/mailman/listinfo/qemu-block>>
> When use cluster_size=1M qcow2 newly created to test "32k rand write">> in 
>the VM,We get low performance within VM。But there are huge “write”>> requests 
>in HOST which falls into qemu stack of"perform_cow".>The reason why this 
>happens is because clusters are the smallest units>of allocation in qcow2. So 
>if you write a new cluster you have to fill>it completely with data. If there 
>was any existing data (backing file,>snapshot), you need to copy it from there.


     But Our image has not backing file or snapshot.>If cluster_size=1M then 
every time you send a write request that needs>to allocate a new cluster then 
you need to write 1MB. It doesn't matter>if the write request is 32KB, 4KB or 
512 bytes.>This problem can be mitigated with smaller clusters. Another 
alternative>is with a feature called 'subcluster allocation', but this is not 
ready>yet: I wrote a prototype and there was a discussion on the mailing 
list>last year, but it's far from complete.>   
https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg01033.html>Berto