Re: [Qemu-devel] [RFC] Disk integrity in QEMU

[Avi Kivity]

Anthony Liguori wrote:
> Avi Kivity wrote:
>> Given that we don't have a zero-copy implementation yet, it is
>> impossible to generate real performance data.
>
> Which means that it's premature to suggest switching the default to
> O_DIRECT since it's not going to help right now.  It can be revisited
> once we can do zero copy but again, I think it should be driven by
> actual performance data.  My main point is that switching to O_DIRECT
> right now is only going to hurt performance for some users, and most
> likely help no one.

I am assuming that we will provide true O_DIRECT support soon.

I don't think O_DIRECT should be qemu's default, since anyone using qemu
directly is likely a "causal virtualization" user.  Management systems
like ovirt should definitely default to O_DIRECT (really, they shouldn't
even offer caching).


>> Now I don't have data that demonstrates how bad these effects are, but I
>> think there is sufficient arguments here to justify adding O_DIRECT.  I
>> intend to recommend O_DIRECT unless I see performance data that favours
>> O_DSYNC on real world scenarios that take into account bandwidth, cpu
>> utilization, and memory utilization (i.e. a 1G guest on a 32G host
>> running fio but not top doesn't count).
>>   
>
> So you intend on recommending something that you don't think is going
> to improve performance today and you know in certain scenarios is
> going to decrease performance?  That doesn't seem right :-)
>

In the near term O_DIRECT will increase performance over the alternative.

> I'm certainly open to changing the default once we get to a point
> where there's a demonstrable performance improvement from O_DIRECT but
> since I don't think it's a given that there will be, switching now
> seems like a premature optimization which has the side effect of
> reducing the performance of certain users.  That seems like a Bad
> Thing to me.

I take the opposite view.  O_DIRECT is the, well, direct path to the
hardware.  Caching introduces an additional layer of code and thus needs
to proven effective.  I/O and memory intensive applications use
O_DIRECT; Xen uses O_DIRECT (or equivalent); I don't see why we need to
deviate from industry practice.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.