From xen-devel-bounces@lists.xen.org Thu Nov 07 14:00:47 2013 Received: (at maildrop) by bugs.xenproject.org; 7 Nov 2013 14:00:47 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1VeQ8d-00087x-Ob for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Thu, 07 Nov 2013 14:00:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VeNNo-000496-CN; Thu, 07 Nov 2013 11:04:16 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VeNN8-00048i-GI for xen-devel@lists.xen.org; Thu, 07 Nov 2013 11:03:34 +0000 Received: from [85.158.137.68:58649] by server-13.bemta-3.messagelabs.com id 65/A6-02689-5837B725; Thu, 07 Nov 2013 11:03:33 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-31.messagelabs.com!1383822211!73612!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.9.13; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26891 invoked from network); 7 Nov 2013 11:03:32 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 7 Nov 2013 11:03:32 -0000 X-IronPort-AV: E=Sophos;i="4.93,651,1378857600"; d="scan'208";a="68982802" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 07 Nov 2013 11:03:31 +0000 Received: from AMSPEX01CL02.citrite.net (10.69.46.33) by FTLPEX01CL03.citrite.net (10.13.107.80) with Microsoft SMTP Server (TLS) id 14.2.342.4; Thu, 7 Nov 2013 06:03:30 -0500 Received: from LONPEX01CL01.citrite.net (10.30.203.101) by AMSPEX01CL02.citrite.net (10.69.46.33) with Microsoft SMTP Server (TLS) id 14.2.342.4; Thu, 7 Nov 2013 12:03:29 +0100 Received: from [10.80.2.80] (10.30.203.1) by LONPEX01CL01.citrite.net (10.30.203.101) with Microsoft SMTP Server id 14.2.342.4; Thu, 7 Nov 2013 11:03:28 +0000 Message-ID: <1383822208.26213.173.camel@kazak.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Thu, 7 Nov 2013 11:03:28 +0000 In-Reply-To: References: <1383046791-1256-1-git-send-email-wei.liu2@citrix.com> <1383046791-1256-2-git-send-email-wei.liu2@citrix.com> <1383321737.672.106.camel@kazak.uk.xensource.com> <20131101161026.GJ4966@zion.uk.xensource.com> <1383322984.672.120.camel@kazak.uk.xensource.com> <20131106103259.GA4659@zion.uk.xensource.com> <1383734464.26213.57.camel@kazak.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.4-3 MIME-Version: 1.0 X-Originating-IP: [10.30.203.1] X-DLP: MIA1 Cc: Wei Liu , Dave Scott , ian.jackson@eu.citrix.com, Jon Ludlam , xen-devel@lists.xen.org, Stefano Stabellini Subject: Re: [Xen-devel] [PATCH V3 1/5] libxl: bump LIBXL_MAXMEM_CONSTANT to 2048 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 create ! title it Remove arbitrary LIBXL_MAXMEM_CONSTANT from libxl, see what breaks thanks On Wed, 2013-11-06 at 18:04 +0000, Stefano Stabellini wrote: > > > > > Happened to come across this when I was looking at other problem. > > > > > > > > > > http://lists.xen.org/archives/html/xen-devel/2009-12/msg00401.html > > > > > > > > > > It looks like that constant was never intended to use in the way it is > > > > > now. Hah. > > > > > > > > Indeed not. > > > > > > > > I vaguely recall that the xapi folks add a bit of slack to the domain > > > > size while they are doing the calculation to see if it fit will on the > > > > host, but not actually when they build the domain. (note that this > > > > therefore only matters for the domain being built, and not cumulatively > > > > for all domains, which makes a difference to the overall overheads on > > > > the system). We could try switching to a model like that and see what > > > > breaks I guess? > > > > > > > > I've CC'd a couple of xapi folks so they can correct my no doubt faulty > > > > memory ;-) > > > > Ian. > > > > > > Xapi experts, any thought? > > > > Andy Cooper told me on IRC > > Xapi adds the slack when building the domain. > > > > Apparently not doing so cause unspecified fallout. Which isn't to say > > that's xapi specific and xl would be fine. > > Yeah.. theoretically I think that we shouldn't have that constat at all. > In practice it could cause stability issues, maybe difficult to narrow > down. Maybe we should remember to remove it at the beginning of the next > development cycle and see what breaks? Keeping in mind that OSSTests is > really unlikely to find any of these issues, we should probably try to > get the community more involved with the testing. The reasons for keeping it are based mostly on folklore rather than an actual understanding of the issues, which may not even be real, and it's wasting (cumulatively) a fair bit of RAM. But waiting until early in the 4.5 cycle is probably a good idea. I've created a bug (with this mail) to remind us to do this. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel