Am 02.07.2014 um 11:29 hat Ming Lei geschrieben: > On Wed, Jul 2, 2014 at 5:12 PM, Kevin Wolf <kw...@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? Hm, okay, I guess backing files might be a valid point. Anything else? Kevin
