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] RFC: [0/2] Remove netloop by lazy copying in netback

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Tue, 27 Mar 2007 12:41:25 +0900
Cc: Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 26 Mar 2007 20:40:18 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070326021947.GA10672@xxxxxxxxxxxxxxxxxxx>
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: <20070325114128.GA5950@xxxxxxxxxxxxxxxxxxx> <C22C2928.C331%Keir.Fraser@xxxxxxxxxxxx> <20070326021947.GA10672@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
On Mon, Mar 26, 2007 at 12:19:47PM +1000, Herbert Xu wrote:
> This is actually one of the reasons I picked the grant tables interface
> originally in that we could unmap it at the same time rather than doing
> a full swap followed by an unmap.
> 
> So are you OK with adding underlying operations that allows a full swap
> of two p2m entries? This would then be used as follows in translated mode:
> 
>       a) new_addr = alloc_page
>       b) memcpy(new_addr, addr, len)
>       c) p2m_swap(__pa(new_addr), __pa(addr))
>       d) grant_unmap(__pa(new_addr))

Swaping the p2m entry on ia64 is easy.
However the following tlb flush cost for the newly allocated page
is extremly high on ia64.
Can alloc_page() at step a) be avoided?
For example batched page allocation and reusing allocated pfns by setting
PG_foreign. And I want arch hook before use/release those pages to
reduce tlb flush cost.
-- 
yamahata

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