From xen-devel-bounces@lists.xen.org Wed Feb 19 01:24:06 2014 Received: (at maildrop) by bugs.xenproject.org; 19 Feb 2014 01:24:06 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WFvtO-0006E9-B2 for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Wed, 19 Feb 2014 01:24:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WFvnT-0002kG-7d; Wed, 19 Feb 2014 01:17:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WFvnR-0002kB-Uw for xen-devel@lists.xen.org; Wed, 19 Feb 2014 01:17:58 +0000 Received: from [85.158.139.211:36552] by server-14.bemta-5.messagelabs.com id E6/7C-27598-54604035; Wed, 19 Feb 2014 01:17:57 +0000 X-Env-Sender: yang.z.zhang@intel.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1392772674!4759363!1 X-Originating-IP: [134.134.136.24] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6487 invoked from network); 19 Feb 2014 01:17:56 -0000 Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by server-6.tower-206.messagelabs.com with SMTP; 19 Feb 2014 01:17:56 -0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 18 Feb 2014 17:13:14 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,503,1389772800"; d="scan'208";a="457769894" Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37]) by orsmga001.jf.intel.com with ESMTP; 18 Feb 2014 17:17:13 -0800 Received: from fmsmsx118.amr.corp.intel.com (10.18.116.18) by FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 18 Feb 2014 17:17:12 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by fmsmsx118.amr.corp.intel.com (10.18.116.18) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 18 Feb 2014 17:17:12 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.227]) by SHSMSX102.ccr.corp.intel.com ([10.239.4.154]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 09:17:09 +0800 From: "Zhang, Yang Z" To: Jan Beulich , George Dunlap , "Xu, Dongxiao" , "Zhang, Xiantao" Thread-Topic: [Xen-devel] [PATCH] Don't track all memory when enabling log dirty to track vram Thread-Index: AQHPJjaWGU8BoIe0JUmrwANmd1LxUZquITGwgAIV/CWAAJImEIAIfYa+///IvYCAAVNtYIAACJYAgAFmyJA= Date: Wed, 19 Feb 2014 01:17:08 +0000 Message-ID: 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: <53035628020000780011D3EE@nat28.tlf.novell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "andrew.cooper3@citrix.com" , Tim Deegan , "Dugger, Donald D" , "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 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. > Jan Best regards, Yang _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel