This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] slow xp hibernation revisited

To: "Keir Fraser" <keir.xen@xxxxxxxxx>, "Tim Deegan" <Tim.Deegan@xxxxxxxxxx>
Subject: RE: [Xen-devel] slow xp hibernation revisited
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Sat, 4 Jun 2011 17:38:46 +1000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 04 Jun 2011 00:39:50 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CA0F91BC.1B9A6%keir.xen@xxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AEC6C66638C05B468B556EA548C1A77D01D5775F@trantor> <CA0F91BC.1B9A6%keir.xen@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwiBQi9TTmL+VIUTGmHL1mgnlOPmgAak8qgAADdoAAAA9fn5AABgqJA
Thread-topic: [Xen-devel] slow xp hibernation revisited
> On 04/06/2011 05:54, "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
> >> 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
> >> far, the bit representing the pfn in entry->valid_mapping is 0
> >> err[] returned for that pfn was -EINVAL.
> >>
> >> Maybe the test is superfluous? Is there a need to do the remap if
> >> the other variables in the expression are satisfied? If the remap
> >> already done and the page could not be mapped last time, what
> >> are there why it would succeed this time?
> >>
> >
> > FWIW, removing the test_bit makes the hibernate go faster than my
> > 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
> > identical parameters could successfully map a page that couldn't be
> > mapped in the previous call, are there any optimisations that could
> > done? Maybe only attempt to map the page being accessed rather than
> > pages in the bucket if the other parameters are identical?
> I'm guessing this happens because of frequent guest CPU access to
> during hibernate? Unfortunately really the qemu checks do make sense,
> 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
> test. Reloading a whole bucket takes bloody ages as they are *huge*:
> in 32-bit qemu; 4MB in 64-bit qemu. It might be easiest to do a test
> 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?

Sounds like a plan. Is there no way to detect the changes to the memory
map of the guest?

Looking past the test_bit call, the next statement does another test and
sets last_address_index to 0 and returns NULL. Is this just to ensure
that the next access isn't just trivially accepted?


Xen-devel mailing list