| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] Segment dirty log for performance
Keir Fraser wrote:
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
No, the performance benefit is not noticeable. We (Robert Phillips,
actually) did it to make migrate more reliable. But relying only on
order-0 allocations is obviously even better. I'll take a look at using
the radix tree as you suggest.
Thanks,
Dave
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home