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] Questions about sh_prefetch and log_dirty

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: Re: [Xen-devel] Questions about sh_prefetch and log_dirty
From: David Knight <dongwei.net@xxxxxxxxxx>
Date: Wed, 24 Jun 2009 21:08:10 +0800
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 24 Jun 2009 06:09:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090624102238.GQ16056@xxxxxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4A410663.7010507@xxxxxxxxxx> <20090624102238.GQ16056@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.22 (Windows/20090605)
Thank you for your reply.
> Hi,
>
> At 17:44 +0100 on 23 Jun (1245779059), David Knight wrote:
>> I've been working on a project which is to minimize the
>> overhead of page_fault when PV is in log_dirty mode. I
>> wrote a function "sh_prebuild", it's very much similar
>> to sh_prefetch(), the major difference between them is:
>> I set the "ft" as "ft_demand_write" rather than
>> "ft_prefetch" when I call l1e_propagate_from_guest().
>
> I'm not sure that's a good idea.  The point of log-dirty is that it lets
> the migration tool resend only the dirtied pages, and although your
> change will avoid some page faults, it will increase the number of
> frames that have to be retransmitted.

Yes, but according to our locality statistics. Marking the nearest 3
or 4 pages as writable will
not be a big problem.
>
> Also, just setting ft_demand_write won't always do what you want: in
> _sh_propagate, if the guest PTE's _PAGE_DIRTY bit isn't set it will mask
> out _PAGE_RW anyway.
>
> That said, I don't understand why your live migrations are failing,
> especially not on the migration _to_ the modified Xen, since the idea
> you describe should be safe.
>

Could it be possible that xen is in log_dirty_mode when a DomU is
immigrating into it ?
> Cheers,
>
> Tim.
>
>> I just want to make the faulted page and its following
>> pages writable and marked as dirty after a write_protect
>> page_fault. The function "sh_prebuild" is called in the
>> sh_page_fault() right before sh_prefetch():
>>
>> ---------------sh_page_fault()-----------------
>>
>> if ( ( shadow_mode_log_dirty(v->domain) )
>> && ( ft == ft_demand_write ) )
>> sh_prebuild(.......);
>>
>> ..............
>>
>> I got problems when I migrate. The code can successfully
>> migrate the domainU to another UNMODIFIED Xen. But when I
>> migrate a domainU from UNMODIFIED Xen back to this MODIFIED
>> Xen, the domU's clock is frozen, I use "xm console" to get
>> in domU's console, but I just got about 6 TSC error messages
>> and no other respond.
>>
>> I am using 32-bit PV domain, no-PSE.
>> Does someone know any reasons? Thanks.
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>



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