From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55371) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cxu7Q-0007D5-Ei for qemu-devel@nongnu.org; Tue, 11 Apr 2017 07:37:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cxu7P-0007jT-Om for qemu-devel@nongnu.org; Tue, 11 Apr 2017 07:37:56 -0400 Date: Tue, 11 Apr 2017 19:37:45 +0800 From: Fam Zheng Message-ID: <20170411113745.GB8507@lemon> References: <20170410150542.30376-1-famz@redhat.com> <20170410150542.30376-10-famz@redhat.com> <20170411100642.GH4516@noname.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170411100642.GH4516@noname.str.redhat.com> Subject: Re: [Qemu-devel] [PATCH for 2.9 v3 09/10] block: Use bdrv_coroutine_enter to start I/O coroutines List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org, Max Reitz , Ed Swierk , Stefan Hajnoczi , Paolo Bonzini On Tue, 04/11 12:06, Kevin Wolf wrote: > > tests/qemu-iotests/109.out | 10 +++++----- > > This one is curious. Why do we copy more data depending on how the job > coroutine is reentered? I did trace it and think the difference is not very important: on master, the second iteration of the mirror_run loop gets a chance to run, and there we have: s->common.len = s->common.offset + (cnt + s->sectors_in_flight) * BDRV_SECTOR_SIZE; E.g. in the mirror job of the first updated output, iter #1 has cnt = 128 and s->sectors_in_flight = 0; iter #2 has cnt = 0, s->sectors_in_flight = 2. I think the reason is simply that co_queue_wakeup in bdrv_coroutine_enter subtly changed how the mirror coroutine and bdrv_co_pwritev are ordered. Fam