From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: RFC: Doing a superpage zero-sweep on decrease_reservation Date: Wed, 09 Mar 2011 15:00:06 +0000 Message-ID: <1299682806.19262.4832.camel@elijah> References: <20110309142335.GI28479@whitby.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110309142335.GI28479@whitby.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tim Deegan Cc: George Dunlap , Paul Durrant , Keir Fraser , "xen-devel@lists.xensource.com" , James Harper List-Id: xen-devel@lists.xenproject.org On Wed, 2011-03-09 at 14:23 +0000, Tim Deegan wrote: > Do you think ballooned-out pages are likely to be in 2MB chunks of > zeroed memory? Sorry, didn't answer this. I think that for a large guest, the initial balloon is very likely that for the first mfn freed in a superpage, that mfn will turn out to have been in a 2MB chunks of zeroed memory, all of which will eventually passed back to Xen anyway. (e.g., imagine a VM with 32GiB static_max but a 16GiB target -- of the 16GiB of individual 4k pages passed back by the balloon driver, the vast majority of them will be in a page which (1) is zeroed already and (2) will end up being passed back entirely anyway.) One could imagine the PV drivers allocating the full balloon size, then going through and sorting the pages by pfn, consolidating the superpages, and passing them back as one big chunk -- but that would be a big waste of time compared to just having Xen optimistically reclaim the whole superpage. -George