From xen-devel-bounces@lists.xen.org Tue Feb 18 11:51:50 2014 Received: (at maildrop) by bugs.xenproject.org; 18 Feb 2014 11:51:50 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WFjDK-0006EI-6F for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Tue, 18 Feb 2014 11:51:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WFj8M-0002X4-O7; Tue, 18 Feb 2014 11:46:42 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WFj8L-0002We-Rg for xen-devel@lists.xen.org; Tue, 18 Feb 2014 11:46:42 +0000 Received: from [85.158.143.35:7471] by server-3.bemta-4.messagelabs.com id 09/F1-11539-E1843035; Tue, 18 Feb 2014 11:46:38 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1392723997!6505079!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 21629 invoked from network); 18 Feb 2014 11:46:37 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Feb 2014 11:46:37 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 18 Feb 2014 11:46:36 +0000 Message-Id: <53035628020000780011D3EE@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.2 Date: Tue, 18 Feb 2014 11:46:32 +0000 From: "Jan Beulich" To: "George Dunlap" , "Dongxiao Xu" , "Xiantao Zhang" , "Yang Z Zhang" 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> <53023239020000780011CED9@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: "andrew.cooper3@citrix.com" , Tim Deegan , DonaldD Dugger , "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 18.02.14 at 04:25, "Zhang, Yang Z" wrote: > Jan Beulich wrote on 2014-02-17: >>>>> On 17.02.14 at 11:18, "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. >> >> Just got done with trying this: By default, things work fine there. >> As soon as I use "iommu=no-snoop", things go bad (even worse than one >> the older box - the guest is consuming about 2.5 CPUs worth of >> processing power _without_ the patch here in use, so I don't even want >> to think about trying it there); I guessed that to be another of the >> potential sources of the problem since on that older box the respective > hardware feature is unavailable. >> >> While I'll try to look into this further, I guess I have to defer to >> our VT-d specialists at Intel at this point... >> > > Hi, Jan, > > I tried to reproduce it. But unfortunately, I cannot reproduce it in my box > (sandy bridge EP)with latest Xen(include my patch). I guess my configuration > or steps may wrong, here is mine: > > 1. add iommu=1,no-snoop in by xen cmd line: > (XEN) Intel VT-d Snoop Control not enabled. > (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. > (XEN) Intel VT-d Queued Invalidation enabled. > (XEN) Intel VT-d Interrupt Remapping enabled. > (XEN) Intel VT-d Shared EPT tables enabled. > > 2. boot a rhel6u4 guest. > > 3. after guest boot up, run startx inside guest. > > 4. a few second, the X windows shows and didn't see any error. Also the CPU > utilization is about 1.7%. > > Any thing wrong? Nothing at all, as it turns out. The regression is due to Dongxiao's http://lists.xenproject.org/archives/html/xen-devel/2013-12/msg00367.html which I have in my tree as part of various things pending for 4.5. And which at the first, second, and third glance looks pretty innocent (IOW I still have to find out _why_ it is wrong). In any case - I'm very sorry for the false alarm. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel