[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH V3] X86/vMCE: handle broken page with regard to migration



On 20/11/12 18:42, Ian Jackson wrote:
Liu, Jinsong writes ("RE: [Xen-devel] [PATCH V3] X86/vMCE: handle broken page with 
regard to migration"):
Ian Jackson wrote:
Liu, Jinsong writes ("RE: [Xen-devel] [PATCH V3] X86/vMCE: handle
broken page with regard to migration"):
No, at last lter, there are 4 points:
1. start last iter
2. get and transfer pfn_type to target
3. copy page to target
4. end last iter
...
It indeed checks mce after point 3 for each page, but what's the
advantage of keeping a separate list?
It avoids yet another loop over all the pages.  Unless I have
misunderstood.  Which I may have, because: if it checks for mce after
point 3 then surely that is sufficient ?  We don't need to worry about
mces after that check.
It's sufficient, but wouldn't each check require a separate hypercall?  
That would surely be slower than just a single hypercall and a loop 
(which is what Jinsong's patch does).
We don't actually need a list -- I think we just need to know, "Have any 
pages broken between reading the p2m table ( xc_get_pfn_type_batch() ); 
if so, we do another full iteration.
Since marking a page broken will also mark it dirty, I suppose what we 
could do is, on the last iteration, clear the dirty bitmap after getting 
the list of pages but before copying them; and then check the bit in the 
bitmap corresponding to the pfn after copying it.
But on the whole, is that really that much *faster* to do it that way?  
Either way you're still adding a single hypercall to the whole thing, 
and one iteration of a loop for each page; but in Jinsong's patch, the 
loop is done all at once, so presumably the compiler / processor will be 
able to do make better use of loop unrolling / registers / the pipeline 
/ branch prediction / caches &c.
The only way to avoid the loop would be to add an extra "have any pages 
been marked broken / dirty" bit somewhere, which is probably more 
trouble than it's worth.
 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.