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: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Sat, 4 Jun 2011 14:54:11 +1000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 03 Jun 2011 21:55:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AEC6C66638C05B468B556EA548C1A77D01D5775E@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>
References: <AEC6C66638C05B468B556EA548C1A77D01D57757@trantor><20110603154337.GT5098@xxxxxxxxxxxxxxxxxxxxxxx> <AEC6C66638C05B468B556EA548C1A77D01D5775E@trantor>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwiBQi9TTmL+VIUTGmHL1mgnlOPmgAak8qgAADdoAA=
Thread-topic: [Xen-devel] slow xp hibernation revisited
> > AIUI the logic in the mapcache is something like:
> >  - Each bucket contains a number of 'locked' mappings (which aren't
> used
> >    for this kind of copy).
> >  - At the bottom of each bucket is a possible 'unlocked' mapping.
> >  - If the unlocked mapping matches the address you want, reuse it
> >  - Else discard it and replace it with a new unlocked mapping to
> >    target area.
> >
> > But something is going on and the "else" clause is happening every
> > time.
> >
> It's the !test_bit(address_offset>>XC_PAGE_SHIFT,
> 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?


Xen-devel mailing list