Xen devel - Oct 2007 - [PATCH] Segment dirty log for performance

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@virtualron.com>
Signed-off-by: Dave Lively <dlively@virtualiron.com>



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

On 24/10/07 22:00, "Ben Guthro" <bguthro@virtualiron.com> 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@virtualron.com>
> Signed-off-by: Dave Lively <dlively@virtualiron.com>
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@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser wrote:
> On 24/10/07 22:00, "Ben Guthro" <bguthro@virtualiron.com>
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@virtualron.com>
>> Signed-off-by: Dave Lively <dlively@virtualiron.com>
>>     
>
> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

On 25/10/07 16:23, "David Lively" <dlively@virtualiron.com>
wrote:
> 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.
Okay, I see. A patch to use only order-0 allocations would be excellent!

 -- Keir



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