From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58770) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2HMu-000411-VO for qemu-devel@nongnu.org; Wed, 02 Jul 2014 06:02:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X2HMl-00007b-TK for qemu-devel@nongnu.org; Wed, 02 Jul 2014 06:02:24 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:45695) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2HMl-00007L-O2 for qemu-devel@nongnu.org; Wed, 02 Jul 2014 06:02:15 -0400 Received: from mail-ve0-f174.google.com ([209.85.128.174]) by youngberry.canonical.com with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1X2HMk-0006SV-Vz for qemu-devel@nongnu.org; Wed, 02 Jul 2014 10:02:15 +0000 Received: by mail-ve0-f174.google.com with SMTP id jx11so10980487veb.33 for ; Wed, 02 Jul 2014 03:02:13 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20140702094958.GG5996@noname.str.redhat.com> References: <20140701152130.GK4587@noname.str.redhat.com> <53B2E82D.8020000@redhat.com> <53B3C059.3060601@redhat.com> <53B3C932.7000700@redhat.com> <20140702091241.GE5996@noname.str.redhat.com> <20140702094958.GG5996@noname.str.redhat.com> Date: Wed, 2 Jul 2014 18:02:13 +0800 Message-ID: From: Ming Lei Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH v2 1/3] block: block: introduce bdrv_io_plug() and bdrv_io_unplug() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Peter Maydell , Fam Zheng , "Michael S. Tsirkin" , qemu-devel , Stefan Hajnoczi , Paolo Bonzini On Wed, Jul 2, 2014 at 5:49 PM, Kevin Wolf wrote: > Am 02.07.2014 um 11:29 hat Ming Lei geschrieben: >> On Wed, Jul 2, 2014 at 5:12 PM, Kevin Wolf 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