qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] Introduce cache images for the QCOW2 format


From: Alex Bligh
Subject: Re: [Qemu-devel] [PATCH] Introduce cache images for the QCOW2 format
Date: Wed, 14 Aug 2013 13:02:27 +0100

On 14 Aug 2013, at 12:42, Kaveh Razavi wrote:

> On 08/14/2013 01:16 AM, Alex Bligh wrote:
>> The above para implies you intend one cache file to be shared by
>> two VMs booting from the same backing image on the same node.
>> If that's true, how do you protect yourself from the following
> 
> Not really. I meant different backing images, and not necessarily
> booting on the same host.

So how does your cache solve the problem you mentioned in that
para?

>> As far as I can see VM1 could read an incomplete write from
>> the cache file.
>> 
>> Further, unless you're opening these files O_DIRECT, how do you
>> know half the writes from VM1 won't be sitting dirty in the page
>> cache when you read using VM2?
> 
> This is essentially the same as what Eric mentioned in his email. As
> long as only one VM writes to the image and it is not simultaneously
> used by other VMs this should not happen.

Correct. So you need one cache file per VM, not one per image.

> There is little benefit in having a second VM reading from the cache
> that is being created by another VM. If the backing file is not opened
> with O_DIRECT, the reads from the first VM will likely exist in the host
> page cache for the second VM.


Correct. So the patch would only speed up the first reboot of
a VM that has already been booted on that node (as you have one
cache file per VM). However, when the second VM boots with the
same image, rather than the pages being hot in the page cache,
it will be loading them from whatever device the cache is on
(as per the above, we need one cache per VM), and whatever that
is, it won't be faster than RAM.

So I fail to see how this speeds things up. Do you have measured
numbers?

I ask because I'm genuinely interested in caching strategies here.
I think the problem is on the write side and not the read side,
particularly where the host page cache is already used (e.g.
cache=writeback) and the image usages ureadahead.

-- 
Alex Bligh







reply via email to

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