Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762128Ab3ECNBK (ORCPT ); Fri, 3 May 2013 09:01:10 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:20507 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755821Ab3ECNBI (ORCPT ); Fri, 3 May 2013 09:01:08 -0400 Date: Fri, 3 May 2013 15:00:36 +0200 From: Daniel Kiper To: Ian Campbell Cc: Konrad Rzeszutek Wilk , Stefano Stabellini , "xen-devel@lists.xensource.com" , "Keir (Xen.org)" , Dave Scott , "james-xen@dingwall.me.uk" , Ian Jackson , "linux-kernel@vger.kernel.org" , Jonathan Ludlam , "darren.s.shepherd@gmail.com" , David Vrabel , "carsten@schiers.de" Subject: Re: [Xen-devel] [PATCH v2 2/2] xen/balloon: Enforce various limits on target Message-ID: <20130503130036.GA12463@debian70-amd64.local.net-space.pl> References: <1367235468-8360-1-git-send-email-daniel.kiper@oracle.com> <1367235468-8360-3-git-send-email-daniel.kiper@oracle.com> <1367246649.3142.316.camel@zakaz.uk.xensource.com> <20130430125952.GD9904@debian70-amd64.local.net-space.pl> <1367329458.3142.524.camel@zakaz.uk.xensource.com> <20130430185852.GF9904@debian70-amd64.local.net-space.pl> <20130502180404.GA16489@phenom.dumpdata.com> <1367568932.28742.19.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1367568932.28742.19.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3023 Lines: 62 On Fri, May 03, 2013 at 09:15:32AM +0100, Ian Campbell wrote: > On Thu, 2013-05-02 at 19:04 +0100, Konrad Rzeszutek Wilk wrote: > > On Thu, May 02, 2013 at 12:34:32PM +0100, Stefano Stabellini wrote: [...] > > > The xapi guys, CC'ed, might have more insights on what exactly is. > > I think that unless someone can remember what this issue was we should > just chalk it up to a historical artefact of something xapi (or maybe > some historical guest) was doing which we have no reason to believe > needs to be carried over to libxl. > > IOW I'm suggesting we set LIBXL_MAXMEM_CONSTANT to 0 early in the 4.4 > cycle and see how it goes. If someone can show either empirical evidence > or (better) logically argue that a fudge is required then we can always > put it back (or it may turn out to be the caller's issue, in which case > they can deal with it, hopefully xapi-on-libxl won't apply this fudge > twice...). > > Alternatively I'm also strongly considering having debug builds of the > toolstack randomise the amount of slack, that ought to shake out any > lingering issues... Do you suggest to postopone this work until 4.4 merge window? If yes, then I think that at least "xen/balloon: Enforce various limits on target" patch (without this crazy libxl hack) should be applied. > > > I dislike having to pull this "hack" into Linux, but if it is actually > > > important to leave LIBXL_MAXMEM_CONSTANT unused, then it is worth doing. > > > I would add a big comment on top saying: > > > > > > "libxl seems to think that we need to leave LIBXL_MAXMEM_CONSTANT > > > kilobytes unused, let's be gentle and do that." > > It seems to me that this change in Linux is really just papering over > the underlying issue. Or at the very least no one has adequately > explained what that real issue is and why this change is relevant to it > and/or an appropriate fix for it. > > The guest knows what target the toolstack has set for it is (its in the > target xenstore node), I don't see any reason for the guest to be > further second guessing that value by examining maxmem (adjusted by a > fudge factor or otherwise). If the guest is seeing failures to increase > its reservation when trying to meet that target then either the > toolstack was buggy in asking it to hit a target greater than its maxmem > or it is hitting one of the other reason for increase reservation > failures. Since it needs to deal with the latter anyway I don't see any > reason to special case maxmem as a cause for a failure. Do not forget that guest may change target itself. Additionally, we would like to introduce xm compatibility mode which is a bit different then xl normal behavior. I do not mention that it is always worth check the limits. It will save us a lot of trouble later. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/