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: Ben Guthro <bguthro@xxxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Segment dirty log for performance
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Thu, 25 Oct 2007 15:25:26 +0100
Cc: Dave Lively <dlively@xxxxxxxxxxxxxxx>
Delivery-date: Thu, 25 Oct 2007 07:26:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <471FB26A.8060603@xxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcgXEuKuIWKxhoMGEdyb3gAX8io7RQ==
Thread-topic: [Xen-devel] [PATCH] Segment dirty log for performance
User-agent: Microsoft-Entourage/11.3.6.070618
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

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