qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] Performance impact of the qcow2 overlap checks


From: Max Reitz
Subject: Re: [Qemu-block] Performance impact of the qcow2 overlap checks
Date: Wed, 1 Feb 2017 13:08:03 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

On 01.02.2017 10:58, John Snow wrote:
> On 01/31/2017 05:28 PM, Max Reitz wrote:
>> On 31.01.2017 13:23, John Snow wrote:
>>> On 01/23/2017 11:29 AM, Max Reitz wrote:

[...]

>>> I think what you are pointing out with refcount blocks not being
>>> essential to protect is probably pretty sufficient as an optimization,
>>> too. Or I guess we can merge your ~real~ series to help optimize things.
>>
>> Or Berto's idea works out to be good enough. :-)
>>
> 
> Follow your dreams!

https://dl.dropboxusercontent.com/u/48755239/savable/gifs/1349921181250.gif

>>> I know in the little qcheck utility I wrote I use RBtrees of ranges that
>>> get merged together; the tool doesn't really care which kinds of
>>> metadata it is, it just knows that it has "metadata" that should be
>>> protected. I think it's fast enough. If the qcow2 is kept fairly
>>> defragmented, it's REALLY fast. IIRC, your patchset has something
>>> similar, so it should be fast enough too.
>>
>> Nothing fancy. It's based on a bitmap of metadata information (more like
>> a nibble-map, though) that is RLE compressed for areas not currently in
>> use. Simple, algorithmically speaking, but makes it harder to calculate
>> the runtime complexity than using a "real" structure, I admit.
>>
>> Max
>>
> 
> It's a real structure! It's just got some properties that are difficult
> to analyze :) You just need to consider a load factor alpha and some
> kind of probabilistic distribution describing sector usage for the
> bitmap, right?

Yes, it's a... errr... Heuristic... Adaptive... Load-balancing...
Algorithm designed specifically for this use case!

> You could probably at least pick a few common cases and calculate that way.
> 
> Or don't. :)

I was taught always to do benchmarks. Even if I could prove that
implementation A always had to be slower than B. Always do benchmarks.
You can never tell anything without.

Good thing you can show anything with benchmarks. I'm not sure yet
whether I want to show my thing to be good or bad, though.

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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