On 05/26/2010 10:40 AM, Aurelien Jarno wrote:
I highly doubt that this is even visible on benchmarks without using
KVM. The improvement on a microbenchmark was relatively small and the
cost from TCG would almost certainly dwarf it.
It is something clearly visible. Before fsync() was not u
Anthony Liguori a écrit :
> On 05/26/2010 09:12 AM, Aurelien Jarno wrote:
>>> It's hard for me to consider this a performance regression because
>>> ultimately, you're getting greater than bare metal performance (because
>>> of extremely aggressive caching). It might be a regression from the
>>> p
Kevin Wolf a écrit :
> Am 26.05.2010 15:42, schrieb Anthony Liguori:
>> On 05/26/2010 03:43 AM, Kevin Wolf wrote:
>>> Am 26.05.2010 03:31, schrieb Anthony Liguori:
>>>
On 05/25/2010 04:01 PM, Aurelien Jarno wrote:
> I really think this patch can be useful, in my own case whe
Anthony Liguori a écrit :
> On 05/26/2010 03:52 AM, Aurelien Jarno wrote:
>> On Tue, May 25, 2010 at 08:31:20PM -0500, Anthony Liguori wrote:
>>
>>> On 05/25/2010 04:01 PM, Aurelien Jarno wrote:
>>>
I really think this patch can be useful, in my own case when testing
debian-inst
On 05/26/2010 04:50 PM, Anthony Liguori wrote:
In fact, btrfs is currently unusable for virt because O_SYNC writes
inflate a guest write to a host write. by a huge factor (50x-100x).
cache=writethrough is 100% unusable, cache=writeback is barely
tolerable. As of 2.6.32, cache=volatile is prob
Am 26.05.2010 16:08, schrieb Anthony Liguori:
> On 05/26/2010 09:03 AM, Kevin Wolf wrote:
>> Am 26.05.2010 15:42, schrieb Anthony Liguori:
>>
>>> On 05/26/2010 03:43 AM, Kevin Wolf wrote:
>>>
Am 26.05.2010 03:31, schrieb Anthony Liguori:
> On 05/25/2010 04:01 PM
On 05/26/2010 09:03 AM, Kevin Wolf wrote:
Am 26.05.2010 15:42, schrieb Anthony Liguori:
On 05/26/2010 03:43 AM, Kevin Wolf wrote:
Am 26.05.2010 03:31, schrieb Anthony Liguori:
On 05/25/2010 04:01 PM, Aurelien Jarno wrote:
I really think this patch can be useful,
On 05/26/2010 09:12 AM, Aurelien Jarno wrote:
It's hard for me to consider this a performance regression because
ultimately, you're getting greater than bare metal performance (because
of extremely aggressive caching). It might be a regression from the
previous performance, but that was at the c
Am 26.05.2010 15:42, schrieb Anthony Liguori:
> On 05/26/2010 03:43 AM, Kevin Wolf wrote:
>> Am 26.05.2010 03:31, schrieb Anthony Liguori:
>>
>>> On 05/25/2010 04:01 PM, Aurelien Jarno wrote:
>>>
I really think this patch can be useful, in my own case when testing
debian-install
On 05/26/2010 08:06 AM, Avi Kivity wrote:
On 05/17/2010 03:58 PM, Anthony Liguori wrote:
On 05/17/2010 05:14 AM, Alexander Graf wrote:
Usually the guest can tell the host to flush data to disk. In some
cases we
don't want to flush though, but try to keep everything in cache.
So let's add a ne
On 05/26/2010 03:52 AM, Aurelien Jarno wrote:
On Tue, May 25, 2010 at 08:31:20PM -0500, Anthony Liguori wrote:
On 05/25/2010 04:01 PM, Aurelien Jarno wrote:
I really think this patch can be useful, in my own case when testing
debian-installer (I already cache=writeback). In short all
On 05/26/2010 03:43 AM, Kevin Wolf wrote:
Am 26.05.2010 03:31, schrieb Anthony Liguori:
On 05/25/2010 04:01 PM, Aurelien Jarno wrote:
I really think this patch can be useful, in my own case when testing
debian-installer (I already cache=writeback). In short all that is about
developin
On 05/25/2010 09:48 PM, Anthony Liguori wrote:
On 05/25/2010 12:59 PM, Alexander Graf wrote:
I see it as the equivalent to the Taint bit in Linux. I want to make
it clear to users up front that if you use this option, and you have
data loss issues, don't complain.
Just putting something in qem
On 05/17/2010 03:58 PM, Anthony Liguori wrote:
On 05/17/2010 05:14 AM, Alexander Graf wrote:
Usually the guest can tell the host to flush data to disk. In some
cases we
don't want to flush though, but try to keep everything in cache.
So let's add a new cache value to -drive that allows us to s
Am 26.05.2010 10:52, schrieb Aurelien Jarno:
> On Tue, May 25, 2010 at 08:31:20PM -0500, Anthony Liguori wrote:
>> On 05/25/2010 04:01 PM, Aurelien Jarno wrote:
>>>
>>> I really think this patch can be useful, in my own case when testing
>>> debian-installer (I already cache=writeback). In short al
On Tue, May 25, 2010 at 08:31:20PM -0500, Anthony Liguori wrote:
> On 05/25/2010 04:01 PM, Aurelien Jarno wrote:
> >
> >I really think this patch can be useful, in my own case when testing
> >debian-installer (I already cache=writeback). In short all that is about
> >developing and testing, as oppo
Am 26.05.2010 03:31, schrieb Anthony Liguori:
> On 05/25/2010 04:01 PM, Aurelien Jarno wrote:
>>
>> I really think this patch can be useful, in my own case when testing
>> debian-installer (I already cache=writeback). In short all that is about
>> developing and testing, as opposed to run a VM in p
On 05/25/2010 04:01 PM, Aurelien Jarno wrote:
I really think this patch can be useful, in my own case when testing
debian-installer (I already cache=writeback). In short all that is about
developing and testing, as opposed to run a VM in production, can
benefit about that. This was one of the or
On Tue, May 25, 2010 at 07:59:18PM +0200, Alexander Graf wrote:
> Anthony Liguori wrote:
> > On 05/17/2010 11:23 AM, Paul Brook wrote:
> I don't see a difference between the results. Apparently the barrier
> option doesn't change a thing.
>
> >>> Ok. I don't like it, but I c
Anthony Liguori wrote:
> On 05/25/2010 12:59 PM, Alexander Graf wrote:
>>> I see it as the equivalent to the Taint bit in Linux. I want to make
>>> it clear to users up front that if you use this option, and you have
>>> data loss issues, don't complain.
>>>
>>> Just putting something in qemu-doc.
On 05/25/2010 12:59 PM, Alexander Graf wrote:
I see it as the equivalent to the Taint bit in Linux. I want to make
it clear to users up front that if you use this option, and you have
data loss issues, don't complain.
Just putting something in qemu-doc.texi is not enough IMHO. Few
people actua
Anthony Liguori wrote:
> On 05/17/2010 11:23 AM, Paul Brook wrote:
I don't see a difference between the results. Apparently the barrier
option doesn't change a thing.
>>> Ok. I don't like it, but I can see how it's compelling. I'd like to
>>> see the documentation improved
Am 17.05.2010 22:07, schrieb Jamie Lokier:
> Alexander Graf wrote:
>>
>> On 17.05.2010, at 18:26, Anthony Liguori wrote:
>>
>>> On 05/17/2010 11:23 AM, Paul Brook wrote:
>> I don't see a difference between the results. Apparently the barrier
>> option doesn't change a thing.
>>
>
Alexander Graf wrote:
>
> On 17.05.2010, at 18:26, Anthony Liguori wrote:
>
> > On 05/17/2010 11:23 AM, Paul Brook wrote:
> I don't see a difference between the results. Apparently the barrier
> option doesn't change a thing.
>
> >>> Ok. I don't like it, but I can see how i
On 17.05.2010, at 18:26, Anthony Liguori wrote:
> On 05/17/2010 11:23 AM, Paul Brook wrote:
I don't see a difference between the results. Apparently the barrier
option doesn't change a thing.
>>> Ok. I don't like it, but I can see how it's compelling. I'd like to
>>> see t
On 05/17/2010 11:23 AM, Paul Brook wrote:
I don't see a difference between the results. Apparently the barrier
option doesn't change a thing.
Ok. I don't like it, but I can see how it's compelling. I'd like to
see the documentation improved though. I also think a warning printed
on st
> > I don't see a difference between the results. Apparently the barrier
> > option doesn't change a thing.
>
> Ok. I don't like it, but I can see how it's compelling. I'd like to
> see the documentation improved though. I also think a warning printed
> on stdio about the safety of the option w
Alexander Graf wrote:
> Anthony Liguori wrote:
>
>> On 05/17/2010 08:17 AM, Alexander Graf wrote:
>>
>>> On 17.05.2010, at 15:09, Anthony Liguori wrote:
>>>
>>>
>>>
On 05/17/2010 08:02 AM, Alexander Graf wrote:
>> My concern is that ext3 exaggerate
28 matches
Mail list logo
