Re: [Qemu-block] null-co undefined read behavior

[Stefan Hajnoczi]

On Wed, Jun 14, 2017 at 07:54:17PM +0200, Kevin Wolf wrote:
> Am 14.06.2017 um 19:44 hat John Snow geschrieben:
> > On 06/13/2017 03:52 AM, Kevin Wolf wrote:
> > > Am 12.06.2017 um 23:20 hat John Snow geschrieben:
> > >> (5) Shut up, John, really, who cares? Please shut up. You are the only
> > >> idiot who would even think to use valgrind ever, and we just don't like
> > >> you that much.
> > > 
> > > (6) Make read-zeroes=on the default. Gives people worse performance if
> > > they expect that null-co:// without any options is the fastest thing
> > > possible, but it has defined behaviour by default which seems good.
> > > 
> > > Whatever solution we choose, I think it should be local to the null
> > > driver, i.e. I don't like (2).
> > 
> > Neither do I, really.
> > 
> > Having read all of the responses, I think I'd like your approach of
> > making read-zeroes the default, and people who "really know what they
> > want" can turn it off and enter the danger zone if they'd like to.
> 
> I expected someone to complain about compatibility, but if nobody
> objects, let's do this.

If I had to track down a performance regression due to this change I
wouldn't be happy with QEMU.

The null driver was introduced for micro-benchmarking.  It's useful for
profiling the virtio-blk request lifecycle, for example.

Changing the performance of the null block driver will throw off
people's benchmarking.  They will have to spend time tracking down this
arbitrary change.

Why should they suffer so you don't have to see Valgrind warnings from
test cases that use legacy image probing?

The test cases can be fixed: either by not using legacy probing or by
adding read-zeroes=on.

Stefan

signature.asc
Description: PGP signature