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/
Home Products Support Community News


Re: [Xen-devel] Regarding page table management changes from Xen v1 to X

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Regarding page table management changes from Xen v1 to Xen v2 (and v3)
From: Himanshu Raj <rhim@xxxxxxxxxxxxx>
Date: Wed, 26 Apr 2006 13:40:57 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 26 Apr 2006 10:41:16 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <d11931952836ca30cdc2dd7a2edb72b1@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: <20060426153556.GB27766@xxxxxxxxxxxxx> <d11931952836ca30cdc2dd7a2edb72b1@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
Although, same results can be obtained by doing the v1.2 way, i.e. making one
hypercall requesting these 1024 changes, no?


On Wed, Apr 26, 2006 at 05:18:28PM +0100, Keir Fraser wrote:
> On 26 Apr 2006, at 16:35, Himanshu Raj wrote:
> >I am trying to understand the rationale behind this change. In 
> >previous case,
> >there would be no page faults due to page table updates and only one 
> >hypercall.
> >In the second case, there would be atleast 2 page faults due to PT 
> >management
> >activity, but no hypercalls. Besides, mapping and remapping with 
> >different permissions
> >imply removing this entry from TLB (which is hopefully being done with 
> >invlpg).
> >Benefit of latter approach only seems to be the removal of xen 
> >specific linux
> >code. Why was the approach changed? Could someone please shed some 
> >light on
> >this?
> It's useful for batched updates (e.g., fork()) where the 2 faults are 
> amortised across up to 1024 pte changes.
>  -- Keir

Himanshu Raj
PhD Student, GaTech (www.cc.gatech.edu/~rhim)
I prefer to receive attachments in an open, non-proprietary format.

Xen-devel mailing list