[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Segment dirty log for performance
On 24/10/07 22:00, "Ben Guthro" <bguthro@xxxxxxxxxxxxxxx> wrote: > Represent dirty log as an array of bitmaps. > Also, when bookkeeping the valid HVM pfn ranges, breaks the PFNs > into two ranges -- RAM and VGA. This allows the dirty > page bitmaps to conform to these ranges and to skip the > (sometimes large) empty PFN range between them. > > Signed-off-by: Ben Guthro <bguthro@xxxxxxxxxxxxxx> > Signed-off-by: Dave Lively <dlively@xxxxxxxxxxxxxxx> In terms of tracking active ranges of pseudophysical space, we already have a data structure that can give that info (the p2m radix tree). And the better way of subdividing the dirty bitmap would be to make that a radix tree too, where the leaves are PAGE_SIZE'd bitmaps each handling 128MB of pseudophys address space. This would mean we only need order-0 allocations in the dirty bitmap logic, greatly reducing the chance of domain-migration failure with ENOMEM. Apart from the obvious benefit of allocating a smaller dirty bitmap, which is hence more likely to succeed, how much does this improve migration performance for a small-ish memory guest? Is it significant? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |