From patchwork Wed Feb 23 16:27:38 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Edgar E. Iglesias" X-Patchwork-Id: 84205 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 69223B7107 for ; Thu, 24 Feb 2011 03:29:45 +1100 (EST) Received: from localhost ([127.0.0.1]:47084 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PsHaw-0007zE-LW for incoming@patchwork.ozlabs.org; Wed, 23 Feb 2011 11:29:42 -0500 Received: from [140.186.70.92] (port=37190 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PsHZ3-0006lo-U3 for qemu-devel@nongnu.org; Wed, 23 Feb 2011 11:27:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PsHZ2-00056o-HF for qemu-devel@nongnu.org; Wed, 23 Feb 2011 11:27:45 -0500 Received: from mail-bw0-f46.google.com ([209.85.214.46]:61883) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PsHZ2-00056a-Ca for qemu-devel@nongnu.org; Wed, 23 Feb 2011 11:27:44 -0500 Received: by bwz15 with SMTP id 15so252106bwz.33 for ; Wed, 23 Feb 2011 08:27:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=Xjko4jm43RMzw3Tr5UKSfJjX1glGp0mbOLwAaHMlUGE=; b=lWidAr9uW85YwWWiiJ7lH5JLxY2zUU0WjMWApRLD8bHoESRXL8o/Hx3njgcb2/Vo2A u+gL/AJHL9Nh4cozSZieFTa+nZaeLnXsGdt1FzsIb045dFtOcmdh3OpekD5qVN1VIYsf u3VtUXsdnrZGaGnsl+MVTL6U80gRoBGLTn5Hg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=rSuuURjudQ4xu1lYwpST86QZ4xFaz6j2WARQjje1weu4QCzlxIJkgghJvgeK/qS24K yTg7CZZfB6VNNkpmmFWurUxQFrw4HKXPTDlY3ms4pHQ6ekMf3bgKMyvOqQYChJPchWKQ 4xFw6lSSq/B92BQCqQ+zDYOqB4eKQfy0MCuus= Received: by 10.204.76.207 with SMTP id d15mr3899074bkk.104.1298478462984; Wed, 23 Feb 2011 08:27:42 -0800 (PST) Received: from localhost (proxy.se.axis.com [195.60.68.148]) by mx.google.com with ESMTPS id w3sm5424894bkt.17.2011.02.23.08.27.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Feb 2011 08:27:40 -0800 (PST) Date: Wed, 23 Feb 2011 17:27:38 +0100 From: "Edgar E. Iglesias" To: Paolo Bonzini Message-ID: <20110223162738.GD27880@edde.se.axis.com> References: <1298278286-9158-1-git-send-email-pbonzini@redhat.com> <20110223101806.GA27880@edde.se.axis.com> <4D64E0B2.3050900@redhat.com> <20110223110850.GB27880@edde.se.axis.com> <4D6500D3.40205@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4D6500D3.40205@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.214.46 Cc: Jan Kiszka , qemu-devel@nongnu.org Subject: [Qemu-devel] Re: [PATCH 0/4] Improve -icount, fix it with iothread X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On Wed, Feb 23, 2011 at 01:42:59PM +0100, Paolo Bonzini wrote: > On 02/23/2011 12:08 PM, Edgar E. Iglesias wrote: > >> > No, this supersedes Marcelo's patch. 10-20% doesn't seem comparable to > >> > "looks like it deadlocked" anyway. Also, Jan has ideas on how to remove > >> > the synchronization overhead in the main loop for TCG+iothread. > > I see. I tried booting two of my MIPS and CRIS linux guests with iothread > > and -icount 4. Without your patch, the boot crawls super slow. Your patch > > gives a huge improvement. This was the "deadlock" scenario which I > > mentioned in previous emails. > > > > Just to clarify the previous test where I saw slowdown with your patch: > > A CRIS setup that has a CRIS and basically only two peripherals, > > a timer block and a device (X) that computes stuff but delays the results > > with a virtual timer. The guest CPU is 99% of the time just > > busy-waiting for device X to get ready. > > > > This latter test runs in 3.7s with icount 4 and without iothread, > > with or without your patch. Sorry, typo here. I ran -icount 10, not 4. > > Thanks for testing this. > > > With icount 4 and iothread it runs in ~1m5s without your patch and > > ~1m20s with your patch. That was the 20% slowdown I mentioned earlier. > > Ok, so it is in both cases with iothread. We go from 16x slowdown to > 19x on one testcase :) and "huge improvement" on another. (Also, the > CRIS images on qemu.org simply hang for me without my patch and numeric > icount---and the watchdog triggers---so that's another factor in favor > of the patches). I guess we can live with the slowdown for now, if > somebody else finds the patch okay. I agree. It would be nice with someone else review aswell though. Jan? > Do you have images for the slow test? the 16x vs 19x slowdown testcase is unfortunately on a proprietary machine which I cant release at the moment. I'll have to debug that case at some point. For the "almost deadlock" testcase, I think the CRIS image on the wiki is OK. With the following patch, the watchdog can be disabled. Run with icount & iothread and you'll see the crawling. With your patch you'll see the the guest booting much faster than before. Still slower than non iothread builds though. In particular if you compare icount 10, with and without iothread. diff --git a/hw/etraxfs_timer.c b/hw/etraxfs_timer.c index 133741b..2223744 100644 --- a/hw/etraxfs_timer.c +++ b/hw/etraxfs_timer.c @@ -197,8 +197,8 @@ static void watchdog_hit(void *opaque) ptimer_run(t->ptimer_wd, 1); qemu_irq_raise(t->nmi); } - else - qemu_system_reset_request(); t->wd_hits++; }