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: James Harper <james.harper@xxxxxxxxxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: Re: [Xen-devel] slow xp hibernation revisited
From: Keir Fraser <keir.xen@xxxxxxxxx>
Date: Sat, 04 Jun 2011 07:39:40 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 03 Jun 2011 23:40:47 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=ufPRVRLhyCSWRlVjFBXuRfOfRWbUssU6nfFlHa4j62I=; b=N5xX4po/pqcTLlC56iBIaglpjJt550fumhHaPIPAqYS+KPdVFNx9slPlszx1yxFh2C yQCArXzYW8VWUyZkT4JifOp77yrMFAqC6PYxYo/oYy1KavYEvZWQxneS6Wl9vzTIrJCO c0YBz78KYaMj1X+y6Is09SBHWTWk1FPxscGKY=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=OKW/qB3efY2THtztZKIPC0hxEYIXgFU/DHdLi+M+VVf58luhOfTqwC4qfs1qhkG4c0 bVE5SN1+Dga1cMoetSRERR8Al614qgHM3vhxHoLo3hrO7Cf0w8LYB54Uya/0glnAInT1 6XPTMO6zwxHCcBOPgaQ9FvhreYOCp3z1oYqus=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AEC6C66638C05B468B556EA548C1A77D01D5775F@trantor>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwiBQi9TTmL+VIUTGmHL1mgnlOPmgAak8qgAADdoAAAA9fn5A==
Thread-topic: [Xen-devel] slow xp hibernation revisited
User-agent: Microsoft-Entourage/
On 04/06/2011 05:54, "James Harper" <james.harper@xxxxxxxxxxxxxxxx> 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

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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Xen-devel mailing list