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] numa=on broken

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] numa=on broken
From: Ryan Harper <ryanh@xxxxxxxxxx>
Date: Sun, 1 Apr 2007 08:46:29 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 01 Apr 2007 14:47:09 +0100
Envelope-to: Keir.Fraser@xxxxxxxxxxxx
In-reply-to: <C2352BDF.538E%Keir.Fraser@xxxxxxxxxxxx>
References: <20070401052018.GA28736@xxxxxxxxxx> <C2352BDF.538E%Keir.Fraser@xxxxxxxxxxxx>
User-agent: Mutt/1.5.6+20040907i
* Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> [2007-04-01 03:28]:
> On 1/4/07 06:20, "Ryan Harper" <ryanh@xxxxxxxxxx> wrote:
> 
> >>> I'm getting ready to re-submit patches to export the topology information
> >>> so the userspace tools can use that info to make intelligent selections.
> >>> This was available back in October, but was never picked up, or even
> >>> commented upon.
> >> 
> >> But can tools make sane automatic decisions on domain creation? And if 
> >> tools
> > 
> > I don't think the tools would do any worse than what an admin would do:
> > keep the domains within a node.
> 
> Well, for example it's not really going to work with the default memory
> allocation policy where dom0 takes all memory and then auto-balloons itself
> down as domains are created. In this situation the domU will end up with
> whatever dom0 happens to have freed up: there's no guarantee of locality.

That's true, but that doesn't mean that as long as there is memory
available in a node that the tool can pick the right cpus that will be
close to the memory.  

> I don't think that auto-ballooning is a particularly sensible setting for
> serious use of Xen. I'd always advise to work out how much memory your dom0
> actually needs and make that a static allocation at boot time. But it is our
> out-of-the-box default: another thing that needs explicit changing (via
> dom0_mem= in this case).

Right.  It looks like then that it would make sense to leave numa off by
default leaving the admin to specify both numa=on and a sensible
dom0_mem in the absence of a mechanism for dom0 to hand back memory from
a specific node, or some page migration mechanism.

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh@xxxxxxxxxx


<Prev in Thread] Current Thread [Next in Thread>