[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
>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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |