> At 01:34 +1000 on 04 Jun (1307151275), James Harper wrote:
> > I'm revisiting the problem where xp hangs on the first hibernation
> > a boot. When the hibernate hangs for a while, strace -T -p shows
> > 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
> > occurs on the first hibernate, never on subsequent hibernates (eg
> > 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
> > 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
> while trying to boot Xen inside Xen. Large memcpys that are handled
> qemu seem to end up wwith a map and unmap for every byte of a REP
> AIUI the logic in the mapcache is something like:
> - Each bucket contains a number of 'locked' mappings (which aren't
> 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
> 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?
Xen-devel mailing list