From xen-devel-bounces@lists.xen.org Tue Feb 18 03:31:40 2014 Received: (at maildrop) by bugs.xenproject.org; 18 Feb 2014 03:31:40 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WFbPI-00013L-Ah for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Tue, 18 Feb 2014 03:31:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WFbJQ-0002VX-57; Tue, 18 Feb 2014 03:25:36 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WFbJO-0002VS-Ho for xen-devel@lists.xen.org; Tue, 18 Feb 2014 03:25:34 +0000 Received: from [193.109.254.147:7560] by server-6.bemta-14.messagelabs.com id 03/DB-03396-AA2D2035; Tue, 18 Feb 2014 03:25:30 +0000 X-Env-Sender: yang.z.zhang@intel.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1392693928!4997605!1 X-Originating-IP: [134.134.136.20] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26402 invoked from network); 18 Feb 2014 03:25:29 -0000 Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by server-8.tower-27.messagelabs.com with SMTP; 18 Feb 2014 03:25:29 -0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 17 Feb 2014 19:25:27 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,499,1389772800"; d="scan'208";a="457160170" Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36]) by orsmga001.jf.intel.com with ESMTP; 17 Feb 2014 19:25:27 -0800 Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 17 Feb 2014 19:25:26 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 17 Feb 2014 19:25:25 -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; Tue, 18 Feb 2014 11:25:21 +0800 From: "Zhang, Yang Z" To: Jan Beulich , George Dunlap , "Zhang, Xiantao" Thread-Topic: [Xen-devel] [PATCH] Don't track all memory when enabling log dirty to track vram Thread-Index: AQHPJjaWGU8BoIe0JUmrwANmd1LxUZquITGwgAIV/CWAAJImEIAIfYa+///IvYCAAVNtYA== Date: Tue, 18 Feb 2014 03:25:21 +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> In-Reply-To: <53023239020000780011CED9@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-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? > Jan Best regards, Yang _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel