From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Yu, Zhang" Subject: Re: [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges. Date: Tue, 2 Feb 2016 23:19:46 +0800 Message-ID: <56B0C912.3040903@linux.intel.com> References: <1454064314-7799-1-git-send-email-yu.c.zhang@linux.intel.com> <1454064314-7799-4-git-send-email-yu.c.zhang@linux.intel.com> <56ABA26C02000078000CC7CD@prv-mh.provo.novell.com> <56ACCAD5.8030503@linux.intel.com> <56AF1CE302000078000CCBBD@prv-mh.provo.novell.com> <20160201120244.GT25660@citrix.com> <56AF5A6402000078000CCEB2@prv-mh.provo.novell.com> <20160201124959.GX25660@citrix.com> <56AF669F02000078000CCF8D@prv-mh.provo.novell.com> <56AF7657.1000200@linux.intel.com> <56AF85A3.6010803@linux.intel.com> <56AF977602000078000CD1BE@prv-mh.provo.novell.com> <56AF89BA.4060105@linux.intel.com> <22191.36960.564997.621538@mariner.uk.xensource.com> <56B093B802000078000CD5FE@prv-mh.provo.novell.com> <56B08B51.2030108@linux.intel.com> <56B09D2B02000078000CD696@prv-mh.provo.novell.com> <56B0B6D0.60303@linux.intel.com> <56B0CE8102000078000CD8D4@prv-mh.provo.novell.com> <56B0C485.8070206@linux.intel.com> <56B0D7A202000078000CD989@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56B0D7A202000078000CD989@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Ian Jackson Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, xen-devel@lists.xen.org, Paul.Durrant@citrix.com, zhiyuan.lv@intel.com, keir@xen.org List-Id: xen-devel@lists.xenproject.org On 2/2/2016 11:21 PM, Jan Beulich wrote: >>>> On 02.02.16 at 16:00, wrote: >> The limit of 4G is to avoid the data missing from uint64 to uint32 >> assignment. And I can accept the 8K limit for XenGT in practice. >> After all, it is vGPU page tables we are trying to trap and emulate, >> not normal page frames. >> >> And I guess the reason that one domain exhausting Xen's memory can >> affect another domain is because rangeset uses Xen heap, instead of the >> per-domain memory. So what about we use a 8K limit by now for XenGT, >> and in the future, if a per-domain memory allocation solution for >> rangeset is ready, we do need to limit the rangeset size. Does this >> sounds more acceptable? > > The lower the limit the better (but no matter how low the limit > it won't make this a pretty thing). Anyway I'd still like to wait > for what Ian may further say on this. > OK then. :) Ian, do you have any suggestions? Thanks Yu