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

[Max Reitz]

On 31.01.2017 14:06, Alberto Garcia wrote:
> On Tue 31 Jan 2017 01:23:33 PM CET, John Snow <address@hidden> wrote:
>>> And of course another approach I already mentioned would be to scrap
>>> the overlap checks altogether once we have image locking (and I guess
>>> we can keep them around in their current form at least until then).
>>
>> I think it's worth having them. Perhaps if you use image locking they
>> can be disabled by default, but I wouldn't really advocate for
>> removing them.
>>
>> 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.
> 
> I think the overhead that most checks add is negligible, so I would not
> remove them. There are maybe three exceptions:
> 
> - refcount-block: this one is slow even for small images, but I think it
>   should be fine after my patch.
> 
> - active-l2: this can be slow if the virtual size of the image is very
>   large. It's still much faster than refcount-block and it can be made
>   faster simply by increasing the cluster size (which makes sense for
>   large images anyway). So I'm not too worried about it.
> 
> - inactive-l2: this is probably the slowest of them all (it even
>   involves reading from disk), but it's only used if there are internal
>   snapshots. I haven't looked into this one.

Also, it's not enabled by default *because* it involves reading from disk.

If we wanted, we could probably just keep the inactive L1 tables in
memory, but I'm not sure we do want that.

> I think the checks as they are now are very simple and it's not worth
> complicating them too much unless we have numbers that prove that
> they're slowing things down. I only got those numbers for the first one.

I personally just think it's plain stupid to iterate through all of the
L1 table before every write access. It just hurts my soul.

Also, we cannot protect inactive L2 tables (because it would be slow, as
you point out), which is kind of not-so-good, too.

Max

signature.asc
Description: OpenPGP digital signature