RE: [Xen-devel] slow xp hibernation revisited

["James Harper" <james.harper@xxxxxxxxxxxxxxxx>]

> 
> > 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
your
> >    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,
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?

James


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel