From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges. Date: Wed, 3 Feb 2016 18:39:03 +0000 Message-ID: <56B24947.4070700@citrix.com> References: <1454064314-7799-1-git-send-email-yu.c.zhang@linux.intel.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> <56B1A7C9.2010708@linux.intel.com> <56B1C93002000078000CDD4B@prv-mh.provo.novell.com> <6b6d0558d3c24f9483ad41d88ced9837@AMSPEX02CL03.citrite.net> <56B2023E02000078000CE01A@prv-mh.provo.novell.com> <7316ea5cb41543d69d7727721368e3c8@AMSPEX02CL03.citrite.net> <56B207EA02000078000CE0A8@prv-mh.provo.novell.com> <9467b97e15bc4cb1b8d6c948ad4fc926@AMSPEX02CL03.citrite.net> <56B20BFA02000078000CE0E7@prv-mh.provo.novell.com> <621ce95774ac4742b96ed9d504c08670@AMSPEX02CL03.citrite.net> <22194.4639.132613.604758@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap , Ian Jackson Cc: Kevin Tian , Wei Liu , Ian Campbell , "xen-devel@lists.xen.org" , Paul Durrant , Stefano Stabellini , "zhiyuan.lv@intel.com" , Jan Beulich , Zhang Yu , "Keir (Xen.org)" List-Id: xen-devel@lists.xenproject.org On 03/02/16 18:21, George Dunlap wrote: > 2. It's not technically difficult to extend the number of servers > supported to something sensible, like 4 (using 4 different write_dm > p2m types) While technically true, spare bits in the pagetable entries are at a premium, and steadily decreasing as Intel are introducing new features. We have 16 current p2m types, and a finite upper bound of 6 bits of p2m type space, already with a push to reduce this number. While introducing 1 new p2m type for this purpose might be an acceptable tradeoff, a using a p2m type per ioreq server is not IMO. As an orthogonal exercise, several of the existing p2m types are redundant and can (or are already) expressed elsehow. There is definitely room to reduce the current 16 types down a bit without too much effort. ~Andrew