On Tue 13 Dec 2016 02:44:26 PM CET, Max Reitz wrote:
But leaving that aside, would that improve anything? I don't think
the cache itself adds any significant overhead here, IIRC even in
your presentation at KVM Forum 2015 qcow2 was comparable to raw as
long as all L2 tables
On 2016-12-13 at 13:55, Alberto Garcia wrote:
On Tue 13 Dec 2016 09:02:34 AM CET, Max Reitz wrote:
I definitely like how simple your approach is, but from a design
standpoint it is not exactly optimal, because O(n) for a cluster
lookup is simply worse than O(1).
It's actually not O(n)
On Tue 13 Dec 2016 09:02:34 AM CET, Max Reitz wrote:
> I definitely like how simple your approach is, but from a design
> standpoint it is not exactly optimal, because O(n) for a cluster
> lookup is simply worse than O(1).
It's actually not O(n) anymore since I rewrote that code last year.
When
On 2016-12-12 at 15:13, Alberto Garcia wrote:
On Fri 09 Dec 2016 03:21:08 PM CET, Max Reitz wrote:
In some scenarios, however, there's a different alternative: if the
qcow2 image is stored in a slow backend (eg. HDD), we could save
memory by putting the L2 cache in a faster one (SSD) instead
On Fri, Dec 09, 2016 at 03:47:03PM +0200, Alberto Garcia wrote:
> as we all know, one of the main things that can make the qcow2 format
> slow is the need to load entries from the L2 table in order to map a
> guest offset (on the virtual disk) to a host offset (on the qcow2
> image).
>
> We have
On Fri 09 Dec 2016 03:21:08 PM CET, Max Reitz wrote:
>> In some scenarios, however, there's a different alternative: if the
>> qcow2 image is stored in a slow backend (eg. HDD), we could save
>> memory by putting the L2 cache in a faster one (SSD) instead of in
>> RAM.
> Well, from a full design
Am 09.12.2016 um 16:00 hat Alberto Garcia geschrieben:
> On Fri 09 Dec 2016 03:18:23 PM CET, Kevin Wolf wrote:
> >> I have been making some tests with exactly that scenario and the
> >> results look good: storing the cache in disk gives roughly the same
> >> performance as storing it in memory.
>
On Fri 09 Dec 2016 03:18:23 PM CET, Kevin Wolf wrote:
>> I have been making some tests with exactly that scenario and the
>> results look good: storing the cache in disk gives roughly the same
>> performance as storing it in memory.
>>
>>
Am 09.12.2016 um 14:47 hat Alberto Garcia geschrieben:
> Hi all,
>
> as we all know, one of the main things that can make the qcow2 format
> slow is the need to load entries from the L2 table in order to map a
> guest offset (on the virtual disk) to a host offset (on the qcow2
> image).
>
> We
Hi all,
as we all know, one of the main things that can make the qcow2 format
slow is the need to load entries from the L2 table in order to map a
guest offset (on the virtual disk) to a host offset (on the qcow2
image).
We have an L2 cache to deal with this, and as long as the cache is big
10 matches
Mail list logo
