From xen-devel-bounces@lists.xen.org Wed Feb 19 08:56:36 2014 Received: (at maildrop) by bugs.xenproject.org; 19 Feb 2014 08:56:36 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WG2xI-0002Re-A9 for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Wed, 19 Feb 2014 08:56:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WG2rz-0007ig-Ru; Wed, 19 Feb 2014 08:51:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WG2ru-0007ib-Tf for xen-devel@lists.xen.org; Wed, 19 Feb 2014 08:51:07 +0000 Received: from [85.158.137.68:7356] by server-15.bemta-3.messagelabs.com id BB/1A-19263-67074035; Wed, 19 Feb 2014 08:51:02 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-31.messagelabs.com!1392799861!1553232!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 22694 invoked from network); 19 Feb 2014 08:51:01 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Feb 2014 08:51:01 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 19 Feb 2014 08:51:00 +0000 Message-Id: <53047E7F020000780011D8E1@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.2 Date: Wed, 19 Feb 2014 08:50:55 +0000 From: "Jan Beulich" To: "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> <53035628020000780011D3EE@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: George Dunlap , "andrew.cooper3@citrix.com" , Tim Deegan , DonaldD Dugger , "xen-devel@lists.xen.org" , Dongxiao Xu , Xiantao Zhang 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 19.02.14 at 02:17, "Zhang, Yang Z" wrote: > Jan Beulich wrote on 2014-02-18: >>>>> 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.h >> tml >> >> 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. >> > > It doesn't matter. Conversely, we need to thank you for helping us to fix > this issue. :) > > BTW, I still cannot reproduce it in my box, even I uses SLES 11 SP3 as > guest. I assume you didn't pull in the broken patch - I'm sure you would see the problem if you did. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel