Re: [Xen-devel] Live migration fails under heavy network use

[John Levon <levon@xxxxxxxxxxxxxxxxx>]

On Wed, Feb 21, 2007 at 07:32:10AM +0000, Keir Fraser wrote:

> >>> Urk. Checkout line 204 of privcmd.c
> >>> That doesn't look too 64b clean to me....
> > 
> > Hmm, I never looked at the Linux privcmd driver before. It seems like
> > you're prefaulting all the pages in the ioctl() in on the ioctl.
> > Currently on Solaris we're demand-faulting each page in the mmap() ...
> > 
> > It looks like we're not checking that we ca actually map the page at the
> > time of the ioctl(), thus it's not ending up as marked with that bit.
> > 
> > Looks like our bug...
> 
> If you check then you may as well map at the same time. I think it would
> actually be hard to defer the mapping in a race-free manner.

I've modified the segment driver to prefault the MFNs and things seem a
lot better for both Solaris and Linux domUs:

(XEN) /export/johnlev/xen/xen-work/xen.hg/xen/include/asm/mm.h:184:d0 Error pfn 
5512: rd=ffff830000f92100, od=0000000000000000, caf=00000000, 
taf=0000000000000002
(XEN) mm.c:590:d0 Error getting mfn 5512 (pfn 47fa) from L1 entry 
0000000005512705 for dom52
(XEN) mm.c:566:d0 Non-privileged (53) attempt to map I/O space 00000000 done
done

Not quite sure why the new domain is trying to map 00000000 though.

I also see a fair amount of:

Dom48 freeing in-use page 2991 (pseudophys 100a4): count=2 type=e8000000

Ian mentioned that these could be harmless. Is this because dom0 has
mapped the page for suspending? And if so, why is the count two not one?

Should xc_core.c really be using MMAPBATCH? I suppose it's convenient
but it does mean that the frame lists have to be locked in memory.

regards,
john

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