From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Lively Subject: Re: [PATCH] Segment dirty log for performance Date: Thu, 25 Oct 2007 11:23:57 -0400 Message-ID: <4720B50D.5090807@virtualiron.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel , Ben Guthro List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 24/10/07 22:00, "Ben Guthro" 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 >> Signed-off-by: Dave Lively >> > > 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