WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Segment dirty log for performance

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Segment dirty log for performance
From: David Lively <dlively@xxxxxxxxxxxxxxx>
Date: Thu, 25 Oct 2007 11:23:57 -0400
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ben Guthro <bguthro@xxxxxxxxxxxxxxx>
Delivery-date: Thu, 25 Oct 2007 08:24:36 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C34665E6.176EC%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C34665E6.176EC%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.5 (X11/20070719)
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

<Prev in Thread] Current Thread [Next in Thread>