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 03:48 PM, Anthony Liguori wrote:
We might get 100 bug reports about this "regression" but they concern
much less than 1 bug report of image corruption because of power
failure/host crash. A reputation of being unsafe is very difficult to
get rid of and is something that I hear conce
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
On 05/17/2010 09:04 AM, 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 exaggerates the cost of fsync
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 set the cache
policy to most aggressive, disabling
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
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 exaggerates the cost of fsync() which will
> result in diminishing value ov
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 exaggerates the cost of fsync() which will result in
diminishing value over time for this feature as people move to ext
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 exaggerates the cost of fsync() which will result
>>> in diminishing value over time for this feature as people move to
>>> ext4/btrfs.
>>>
>> There will be ext3 file
On 05/17/2010 08:02 AM, Alexander Graf wrote:
My concern is that ext3 exaggerates the cost of fsync() which will result in
diminishing value over time for this feature as people move to ext4/btrfs.
There will be ext3 file systems for years out. Just because people can use
better and fast
On 17.05.2010, at 14:58, 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 a
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 set the cache
policy to most aggressive, disabling
Am 17.05.2010 12:14, schrieb Alexander Graf:
> 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 set the cache
> policy to most aggressive, di
38 matches
Mail list logo
