[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel][PATCH]Provide 3 times continously writes check andunshadow the guest page
Hi, At 15:14 +0800 on 31 Jan (1201792446), Tian, Kevin wrote: > I noted that existing early unshadow heuristic has one exception > on top level page table. I guess the reason is to avoid incorrect > unshadow on top level which implicates whole address space > being unshadowed with heavy overhead to be re-shadowed later. > Also if top level page table is pointed by current guest CR3, it's > sure not an indicator for unshadow. Actually that's a hangover from the original version of this heuristic, where we special-cased the top-level shadows by zeroing out non-xen entries, even if they couldn't be unshadowed. The current version has lost the special-case handling but not replaced it with anything. Well spotted - I'll fix it. > But now I'm considering whether we can release that check on > top level page table if it's not pinned by current guest CR3. Take > Xiaohui's iperf case for example, she found incorrectly shadowed > pages are mostly L2 pages on 32 and 32pae. Interesting! > I guess thrash results in Xiaohui's test results may come from > such heuristics applied to leaf pages also which is too aggre- > sive in same cases. But for top level pages, we may be able > to catch up one heuristics then... :-) The unshadow-after-N-writes heuristic is designed to catch pagetables getting reused as data pages, and the existing early-unshadow heuristic is designed to spot process teardown, so there's possibly value in having both. Cheers, Tim. -- Tim Deegan <Tim.Deegan@xxxxxxxxxx> Principal Software Engineer, Citrix Systems (R&D) Ltd. [Company #02300071, SL9 0DZ, UK.] _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |