From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH 3/4] kvm tools: Add debug feature to test the IO thread Date: Tue, 19 Apr 2011 19:11:16 +0200 Message-ID: <20110419171116.GD6640@elte.hu> References: <1303131754-25072-1-git-send-email-levinsasha928@gmail.com> <1303131754-25072-3-git-send-email-levinsasha928@gmail.com> <1303232667.6697.5.camel@stimpy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Pekka Enberg , asias.hejun@gmail.com, gorcunov@gmail.com, prasadjoshi124@gmail.com, kvm@vger.kernel.org To: Sasha Levin Return-path: Received: from mx2.mail.elte.hu ([157.181.151.9]:48905 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753663Ab1DSRLW (ORCPT ); Tue, 19 Apr 2011 13:11:22 -0400 Content-Disposition: inline In-Reply-To: <1303232667.6697.5.camel@stimpy> Sender: kvm-owner@vger.kernel.org List-ID: * Sasha Levin wrote: > On Tue, 2011-04-19 at 19:52 +0300, Pekka Enberg wrote: > > On Mon, Apr 18, 2011 at 4:02 PM, Sasha Levin wrote: > > > Add --debug-io-delay-cycles and --debug-io-delay-amount to delay the completion of IO requests within virtio-blk. > > > This feature allows to verify and debug the threading within virtio-blk. > > > > > > Signed-off-by: Sasha Levin > > > > Well, to be honest, I'm not convinced we need both of these. Isn't > > --debug-io-delay= enough for our use? > > This came up during our testing. > > Ingo suggested a large delay so we could easily see the results of > threading. The problem we encountered was that having a delay right from > the beginning will make the guest kernel take a rather long time to boot > and would make actually testing the threading impossible. > > I've added a delay before the activation of the I/O request completion > delay to give the tester/debugger enough time to boot into the guest and > prepare anything needed for the test. > > Making it a constant is also rather hard because different kernels can > take a very different amount of I/O requests to boot. Take the simple > example of a whether fsck was running during the boot or not. I suspect we'll eventually want to have some sort of 'kvm set' subcommand that can modify attributes of running instances? Setting the debug delay would be one of the options: kvm set MyInstance-1 --debug-io-delay-ms 10000 That way the delay can be activated in a suitable moment - and disabled again after testing: kvm set MyInstance-1 --debug-io-delay-ms 0 ? Thanks, Ingo