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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Tim Deegan
>Sent: 2008年1月28日 17:49
>
>Hi,
>
>At 09:49 +0000 on 24 Jan (1201168161), Tim Deegan wrote:
>> The measurements you gave look like it fixes
>> one particularly bad case very well, but makes overall performance
>> worse.  In that case, I'm wondering whether there might be a 
>better way
>> of fixing the network-buffer issue without degrading general
>> performance.
>
>What's the trade-off if you use numbers other than three in this
>heuristic?  Does a higher number still detetct data pages without
>harming the general performance so much?
>
>Cheers,
>
>Tim.
>

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.

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. So the point is 
whether OS may update top level page tables continuously like 
by 2 continuous zero writes or 3 continuous writes:

    * At fork, parent mappings are modified to RO, but normally
on leaf entry. Child page table is not active yet at mm clone

    * At exit, normally user VMAs are free-ed one by one and top
level page is unlikey to be seen continuous writes. After user
VMAs are free-ed, it's easy to free whole pgd directly without 
further touch. That's one corner case Xiaohui's patch tries to 
solve when it's used later as data page.

    * OS may also put some special pattern in batch style
like from swap thread. But reasonably those patterns are put
in leaf entries, and continuous touch on top level is less likely.

Please correct me since definitely I may miss important OS
behaviors. If above assumption is true, we may use a heuristic
combo on top of Xiaohui's patch:
    <3 continuous writes on INACTIVE top level page table>

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... :-)

Thanks,
Kevin

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