RE: slow xp hibernation revisited

["James Harper" <james.harper@bendigoit.com.au>]

> At 01:34 +1000 on 04 Jun (1307151275), James Harper wrote:
> > I'm revisiting the problem where xp hangs on the first hibernation
after
> > a boot. When the hibernate hangs for a while, strace -T -p shows
around
> > 600/second of:
> >
> > mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0) =
> > 0x7fb9cfa38000 <0.000036>
> > ioctl(6, IOCTL_PRIVCMD_MMAPBATCH_V2, 0x7fff2c8b0f20) = -1 EINVAL
> > (Invalid argument) <0.000027>
> > ioctl(6, IOCTL_PRIVCMD_MMAPBATCH, 0x7fff2c8b0f40) = 0 <0.002878>
> > munmap(0x7fb9cfa38000, 1048576) = 0 <0.000111>
> >
> > Nothing like that is seen during normal execution, and the pause
only
> > occurs on the first hibernate, never on subsequent hibernates (eg
after
> > resume then hibernate again) until the DomU is rebooted. Working
> > backwards, those ioctl's appear to be called in libxc from
> > xc_map_foreign_xxx, but I'm getting a bit lost from there. Any
> > suggestions on how to track down what is causing this? Originally I
> > thought it might have been PoD memory causing the performance hit
but
> > this DomU is fully populated aside from a few hundred kb.
> 
> I think this is a bug in the qemu-dm mapcache code, which I saw
recently
> while trying to boot Xen inside Xen.  Large memcpys that are handled
by
> qemu seem to end up wwith a map and unmap for every byte of a REP
MOVSB.
> 
> 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.
> 
> Unfortunately that's as far as I got before I needed to work on
> something else. :(
> 

Can you take a guess at what DomU behaviour would trigger the above?

Thanks

James