Re: [Xen-devel][PATCH]Provide 3 times continously writes check andunshadow the guest page

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

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