From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: RFC: Doing a superpage zero-sweep on decrease_reservation Date: Wed, 9 Mar 2011 14:23:35 +0000 Message-ID: <20110309142335.GI28479@whitby.uk.xensource.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: George Dunlap Cc: James, Paul Durrant , Keir Fraser , "xen-devel@lists.xensource.com" , Harper List-Id: xen-devel@lists.xenproject.org Hi, At 13:47 +0000 on 09 Mar (1299678468), George Dunlap wrote: > It occured to me, it might be simpler if we check for a zero superpage > when doing a decrease_reservation call instead. We'd only do a sweep > if the p2m entry is currently a superpage. If that's the case, we > sweep the superpage containing that mfn and nothing else. If the > whole superpage isn't zero, we'll shatter the superpage in the p2m > tables, so that even if we get an mfn from the same page again, we > won't scan it. Do you think ballooned-out pages are likely to be in 2MB chunks of zeroed memory? Apart from avoiding shattering and re-gathering a 2MB p2m range (which is nice, but proabbly not the perf bottleneck for PoD right now), this is a change from scanning arbitrary memory when we run out to scanning memory around balloon sites as we go. If this is likely to have a high hit rate, great. If not, it might be (overall) worse because we waste time scanning as we balloon and have to do the full scan later anyway. > I was going to say, "scan only if the number of p2m entries is higher > than the number of entries in the cache". But it occurred to me, it > might not be a bad idea to scan for zero pages in any case -- so that > we can consolidate even after the guest has been running for a while. I'm not so keen on that - AFAICS once we've passed #pod-entries == #pod-pages, we shouldn't be doing any expensive work for PoD. We might want to think about defragging HVM guests independently of the PoD stuff, though. Cheers, Tim. -- Tim Deegan Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)