Re: [Xen-devel] slow xp hibernation revisited

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

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. :( 

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

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