From xen-devel-bounces@lists.xen.org Mon Feb 17 12:43:26 2014 Received: (at maildrop) by bugs.xenproject.org; 17 Feb 2014 12:43:26 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WFNXi-0000M4-PY for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Mon, 17 Feb 2014 12:43:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WFNSL-0007gM-BF; Mon, 17 Feb 2014 12:37:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WFNSJ-0007gH-AI for xen-devel@lists.xen.org; Mon, 17 Feb 2014 12:37:51 +0000 Received: from [85.158.143.35:55156] by server-1.bemta-4.messagelabs.com id 3F/B1-31661-E9202035; Mon, 17 Feb 2014 12:37:50 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1392640668!6221355!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ4MDU=\n X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27733 invoked from network); 17 Feb 2014 12:37:48 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Feb 2014 12:37:48 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 17 Feb 2014 12:37:48 +0000 Message-Id: <530210A8020000780011CDD5@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.2 Date: Mon, 17 Feb 2014 12:37:44 +0000 From: "Jan Beulich" To: "George Dunlap" , "Yang Z Zhang" ,"Tim Deegan" References: <20140210080314.GA758@deinos.phlegethon.org> <20140211090202.GC92054@deinos.phlegethon.org> <20140211115553.GB97288@deinos.phlegethon.org> <52FA2C63020000780011B201@nat28.tlf.novell.com> <52FA480D.9040707@eu.citrix.com> <52FCE8BE.8050105@eu.citrix.com> <52FCF90F020000780011C29A@nat28.tlf.novell.com> <20140213162022.GE82703@deinos.phlegethon.org> <5301F000020000780011CCE0@nat28.tlf.novell.com> <5301FF51.1060509@eu.citrix.com> In-Reply-To: <5301FF51.1060509@eu.citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "andrew.cooper3@citrix.com" , Xiantao Zhang , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Don't track all memory when enabling log dirty to track vram X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 17.02.14 at 13:23, George Dunlap wrote: > On 02/17/2014 10:18 AM, Jan Beulich wrote: >> And second, I have been fighting with finding both conditions >> and (eventually) the root cause of a severe performance >> regression (compared to 4.3.x) I'm observing on an EPT+IOMMU >> system. This became _much_ worse after adding in the patch here >> (while in fact I had hoped it might help with the originally observed >> degradation): X startup fails due to timing out, and booting the >> guest now takes about 20 minutes). I didn't find the root cause of >> this yet, but meanwhile I know that >> - the same isn't observable on SVM >> - there's no problem when forcing the domain to use shadow >> mode >> - there's no need for any device to actually be assigned to the >> guest >> - the regression is very likely purely graphics related (based on >> the observation that when running something that regularly but >> not heavily updates the screen with X up, the guest consumes a >> full CPU's worth of processing power, yet when that updating >> doesn't happen, CPU consumption goes down, and it goes further >> down when shutting down X altogether - at least as log as the >> patch here doesn't get involved). >> This I'm observing on a Westmere box (and I didn't notice it earlier >> because that's one of those where due to a chipset erratum the >> IOMMU gets turned off by default), so it's possible that this can't >> be seen on more modern hardware. I'll hopefully find time today to >> check this on the one newer (Sandy Bridge) box I have. > > So you're saying that the slowdown happens if you have EPT+IOMMU, but > *not* if you have EPT alone (IOMMU disabled), or shadow + IOMMU? > > I have an issue I haven't had time to look into where windows installs > are sometimes terribly slow on my Nehalem box; but it seems to be only > with qemu-xen, not qemu-traditional. I haven't tried with shadow. Sorry I forgot to mention this - I too suspected the qemu version update to be one possible reason, but I'm seeing the same behavior with qemu-trad. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel