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: eliminating 166G limit (was Re: [Xen-devel] Problem with nr_nodes on

To: Jan Beulich <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: eliminating 166G limit (was Re: [Xen-devel] Problem with nr_nodes on large memory NUMA machine)
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 27 Nov 2007 08:56:27 +0000
Delivery-date: Tue, 27 Nov 2007 00:51:00 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <474BE6C2.76E4.0078.0@xxxxxxxxxx>
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: Acgw02Tzo16GQJzGEdyEaQAWy6hiGQ==
Thread-topic: eliminating 166G limit (was Re: [Xen-devel] Problem with nr_nodes on large memory NUMA machine)
User-agent: Microsoft-Entourage/11.3.6.070618
On 27/11/07 08:43, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> I think page allocation in this path isn't nice, at least not without success
> guarantee (not the least because because netback doesn't check return
> values). I would therefore rather see a solution in placing the burden of
> ensuring accessibility on the producer (netback) of the page, and fail the
> transfer if the destination domain can't access the page (whether to be
> nice and try an allocate-and-copy operation here is a secondary thing).
> 
> Netback would then need to determine the address size of netfront's domain
> (just like blkback and blktap do, except that HVM domains should also be
> treated as not requiring address restriction), and have two pools of pages
> for use in transfers - one unrestricted and one limited to 37 address bits
> (the
> two could be folded for resource efficiency if the machine has less than
> 128G). Besides that, netback would also start checking return values of the
> multicall pieces.

I don't get how your netback approach works. The pages we transfer do not
originate from netback, so it has little control over them. And, even if it
did, when we allocate pages for network receive we do not know which
domain's packet will end up in each buffer.

Personally I think doing it in Xen is perfectly good enough for supporting
this very out-of-date network receive mechanism.

 -- Keir



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