From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: slow xp hibernation revisited Date: Sat, 04 Jun 2011 07:39:40 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: 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: James Harper , Tim Deegan Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 04/06/2011 05:54, "James Harper" wrote: >> It's the !test_bit(address_offset>>XC_PAGE_SHIFT, > entry->valid_mapping) >> that is causing the if expression to be true. From what I can see so >> far, the bit representing the pfn in entry->valid_mapping is 0 because >> err[] returned for that pfn was -EINVAL. >> >> Maybe the test is superfluous? Is there a need to do the remap if all >> the other variables in the expression are satisfied? If the remap was >> already done and the page could not be mapped last time, what reasons >> are there why it would succeed this time? >> > > FWIW, removing the test_bit makes the hibernate go faster than my screen > can refresh over a slow DSL connection and in a quick 30 second test > doesn't appear to have any adverse effects. > > If there is a chance that a subsequent call to qemu_remap_bucket with > identical parameters could successfully map a page that couldn't be > mapped in the previous call, are there any optimisations that could be > done? Maybe only attempt to map the page being accessed rather than all > pages in the bucket if the other parameters are identical? I'm guessing this happens because of frequent guest CPU access to non-RAM during hibernate? Unfortunately really the qemu checks do make sense, I'd say, since the memory map of the guest can be changed dynamically , and we currently only flush the map_cache on XENMEM_decrease_reservation hypercalls. One fix would be for Xen to know which regions of non-RAM are actually emulated device areas, and only forward those to qemu. It could then quick-fail on the rest. However, the easiest fix would be to only re-try to map the one pfn under test. Reloading a whole bucket takes bloody ages as they are *huge*: 256kB in 32-bit qemu; 4MB in 64-bit qemu. It might be easiest to do a test re-map of the one page to a scratch area, then iff it succeeds, *then* call qemu_remap_bucket(). Then you remap the bucket only if something really has changed, and you don't have to mess too much with modifying the bucket yourself outside of remap_bucket. How does that sound? -- Keir > James > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel