Re: [Qemu-devel] [PATCH v2 1/3] block: block: introduce bdrv_io_plug() and bdrv_io_unplug()

[Ming Lei <ming.lei@canonical.com>]

On Wed, Jul 2, 2014 at 5:49 PM, Kevin Wolf <kwolf@redhat.com> wrote:
> Am 02.07.2014 um 11:29 hat Ming Lei geschrieben:
>> On Wed, Jul 2, 2014 at 5:12 PM, Kevin Wolf <kwolf@redhat.com> wrote:
>> > Am 02.07.2014 um 10:56 hat Paolo Bonzini geschrieben:
>> >> Il 02/07/2014 10:39, Ming Lei ha scritto:
>> >> >Then start to read payload in original path, but no plug/unplug any
>> >> >more. Also another request may follows, and another plug&unplug
>> >> >comes too, which makes thing more complicated, so I suggest to
>> >> >enable plug&unplug only for raw driver now.
>> >>
>> >> That's just a performance issue (and actually one that wasn't in 2.0
>> >> because qcow2 on dataplane wasn't supported there).  In many cases
>> >> the cache hit of the qcow2 metadata cache can be very high, and
>> >> avoiding plug/unplug would prevent an easy performance bonus.
>> >>
>> >> I don't especially like plug/unplug as an API (I think it's better
>> >> to extend aio_multiwrite to include other kind of requests), but:
>> >>
>> >> - either we have qualms on the correctness of it, and then we should
>> >> live with the regressions
>> >>
>> >> - or if the patches are not messy and reverting them is easy, we
>> >> should go for it.  This is what we did for dataplane in the first
>> >> place, and we can keep doing it in the 2.1 dataplane code.
>> >
>> > Fully agree. This series is small enough and obviously fixes a
>> > dataplane problem, so at least for 2.1 we should go for it.
>> >
>> > My thoughts in the other mail were more about where to go in the long
>> > term. We need to have a decision about what API we commit to - something
>> > multiwrite-like or something plug/unplug-like - before we want to start
>> > converting everything to that interface.
>> >
>> > This is why I think we should be thinking about how to implement certain
>> > optimisations (like the request merging with plug/unplug, as I mentioned;
>> > or mixing read and writes in one batch with multiwrite) in both models.
>> > Only when we have a reasonbly good idea of what the result would look
>> > like in either case we can make an informed decision.
>>
>> Actually linux-aio can support to submit read/write to multi files, and
>> virtio-scsi does have the use case, so in future io queue should be
>> per aio-context as I posted 1st time.  And I am wondering if multiwrite-like
>> APIs can fit in this situation.
>
> Though where would you get the requests for two different files from,
> within the same bdrv_plug/unplug block?

I think it is doable if io queue is per aio_context.

The requests can be sent to different luns(files), see virtio_scsi_handle_cmd().

Thanks,
--
Ming Lei