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 wer
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) anymore
On Tue, 12/13 13:29, Kevin Wolf wrote:
> Am 13.12.2016 um 11:16 hat Fam Zheng geschrieben:
> > On Tue, 12/13 09:02, Max Reitz wrote:
> > > > Yes but the use case is that the qcow2 image is stored in a slow disk,
> > > > so things will be faster if we avoid having to read it too often.
> > > >
> >
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
Am 13.12.2016 um 11:16 hat Fam Zheng geschrieben:
> On Tue, 12/13 09:02, Max Reitz wrote:
> > > Yes but the use case is that the qcow2 image is stored in a slow disk,
> > > so things will be faster if we avoid having to read it too often.
> > >
> > > But the data is there and it needs to be read,
On Tue, 12/13 09:02, Max Reitz wrote:
> > Yes but the use case is that the qcow2 image is stored in a slow disk,
> > so things will be faster if we avoid having to read it too often.
> >
> > But the data is there and it needs to be read, so we have three options:
> >
> > 1) Read it everytime we
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 of
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.
>>
>> |-++--++---
On 09.12.2016 14:47, Alberto Garcia wrote:
> 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 cac
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 ha
12 matches
Mail list logo
