From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Claim mode and HVM PoD interact badly Date: Fri, 10 Jan 2014 11:39:44 -0500 Message-ID: <20140110163944.GB21692@phenom.dumpdata.com> References: <20140110115638.GG29180@zion.uk.xensource.com> <1389355182.19142.38.camel@kazak.uk.xensource.com> <20140110145807.GB19124@phenom.dumpdata.com> <1389366985.19142.64.camel@kazak.uk.xensource.com> <20140110152840.GA20385@phenom.dumpdata.com> <1389369373.6423.21.camel@kazak.uk.xensource.com> <20140110160536.GB21360@phenom.dumpdata.com> <1389370275.6423.26.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1389370275.6423.26.camel@kazak.uk.xensource.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: Ian Campbell Cc: George Dunlap , Ian Jackson , Wei Liu , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Fri, Jan 10, 2014 at 04:11:15PM +0000, Ian Campbell wrote: > On Fri, 2014-01-10 at 11:05 -0500, Konrad Rzeszutek Wilk wrote: > > On Fri, Jan 10, 2014 at 03:56:13PM +0000, Ian Campbell wrote: > > > On Fri, 2014-01-10 at 10:28 -0500, Konrad Rzeszutek Wilk wrote: > > > > On Fri, Jan 10, 2014 at 03:16:25PM +0000, Ian Campbell wrote: > > > > > On Fri, 2014-01-10 at 09:58 -0500, Konrad Rzeszutek Wilk wrote: > > > > > > Which implies to me that we _need_ the 'maxmem' amount of memory at boot time. > > > > > > And then it is the responsibility of the balloon driver to give the memory > > > > > > back (and this is where the 'static-max' et al come in play to tell the > > > > > > balloon driver to balloon out). > > > > > > > > > > PoD exists purely so that we don't need the 'maxmem' amount of memory at > > > > > boot time. It is basically there in order to let the guest get booted > > > > > far enough to load the balloon driver to give the memory back. > > > > > > > > > > It's basically a boot time zero-page sharing mechanism AIUI. > > > > > > > > But it does look to gulp up hypervisor memory and return it during > > > > allocation of memory for the guest. > > > > > > It should be less than the maxmem-memory amount though. Perhaps because > > > Wei is using relatively small sizes the pod cache ends up being a > > > similar size to the saving? > > > > > > Or maybe I just don't understand PoD, since the code you quote does seem > > > to contradict that. > > > > > > Or maybe libxl's calculation of pod_target is wrong? > > > > > > > From reading the code the patch seems correct - we will _need_ that > > > > extra 128MB 'claim' to allocate/free the 128MB extra pages. They > > > > are temporary as we do free them. > > > > > > It does makes sense that the PoD cache should be included in the claim, > > > I just don't get why the cache is so big... > > > > I think it expands and shrinks to make sure that the memory is present > > in the hypervisor. If there is not enough memory it would -ENOMEM and > > the toolstack would know immediately. > > > > But that seems silly - as that memory might be in the future used > > by other guests and then you won't be able to use said cache. But since > > it is a "cache" I guess that is OK. > > Wait, isn't the "cache" here just the target memory size? The delta of it: maxmem - memory. > > PoD uses up to that size to populate guest pages, and will try to > reclaim zeroed pages from the guest so that it never grows bigger than > the target size. The way I read the code it has a split personality: - up to 'memory' in the toolstack are allocated. - the delta of 'maxmem - memory' are allocated in the hypervisor and then freed. > > I think the confusion here is that Wei had target=128M and maxmem=256M > so the difference was 128M which served as a nice red-herring... This is confusing indeed. > > Ian >