From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39211) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Utc4w-0004HO-4v for qemu-devel@nongnu.org; Mon, 01 Jul 2013 07:15:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Utc4u-0005NZ-VP for qemu-devel@nongnu.org; Mon, 01 Jul 2013 07:15:30 -0400 Received: from mail.avalus.com ([2001:41c8:10:1dd::10]:47837) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Utc4u-0005Kg-Pr for qemu-devel@nongnu.org; Mon, 01 Jul 2013 07:15:28 -0400 Date: Mon, 01 Jul 2013 12:15:14 +0100 From: Alex Bligh Message-ID: <6BA64425336EDA4E319139B5@Ximines.local> In-Reply-To: <20130701102353.GB9000@dhcp-200-207.str.redhat.com> References: <1372528923-12354-1-git-send-email-alex@alex.org.uk> <1372528923-12354-2-git-send-email-alex@alex.org.uk> <20130701102353.GB9000@dhcp-200-207.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [Qemu-devel] [PATCH] Add delay option to blkdebug Reply-To: Alex Bligh List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Alex Bligh , qemu-devel@nongnu.org, stefanha@redhat.com Kevin, --On 1 July 2013 12:23:53 +0200 Kevin Wolf wrote: > "inject-error" doesn't really describe this well. Shouldn't we rather > introduce a new section "[delay]" or something like that? That's how I started off. Then I realised you might want to make the delay dependent on the sector or state, or the operation concerned. Changing the name of the section to '[inject]' would probably be best. > I remember that I once tried something similar, but never submitted it. > I think the reason was that using timers inside requests doesn't really > work. It works as long as everything is indeed asynchronous, but > bdrv_drain_all() or a loop waiting for a single request that tries to > make progress with qemu_aio_wait() will simply hang because timers > aren't processed in these nested event loops. Yes I discovered that the hard way. In particular, timers are not run at all in (e.g.) qemu-img. I think they are not run at all outside qemu itself. This is why I don't use timers. What it currently does is schedule a bh which looks at the time (as time still moves forwards) - using idle scheduling, and if it's not time to run the bh, the bh reschedules itself (using idle scheduling again). Because of the use of idle scheduling it isn't busy-waiting, but it is hardly ideal. I /think/ this is safe because if bh's aren't running, lots of drivers (e.g. blkverify) would not work. And as far as I can tell, idle bh's are scheduled whenever non-idle ones are. However, I am newbie as far as the async code and the block code are concerned. -- Alex Bligh