From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH V3] X86/vMCE: handle broken page with regard to migration Date: Wed, 21 Nov 2012 11:34:40 +0000 Message-ID: <50ACBC50.4040204@eu.citrix.com> References: <446f6b9bfc89137e1aa0.1353117881@ljsromley.bj.intel.com> <20651.51754.974511.264479@mariner.uk.xensource.com> <20651.52995.774236.722303@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20651.52995.774236.722303@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: "Liu, Jinsong" , "xen-devel@lists.xensource.com" , Ian Campbell , Jan Beulich List-Id: xen-devel@lists.xenproject.org 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