Re: numa=on broken

[Ryan Harper <ryanh@us.ibm.com>]

* Keir Fraser <Keir.Fraser@cl.cam.ac.uk> [2007-04-01 03:28]:
> On 1/4/07 06:20, "Ryan Harper" <ryanh@us.ibm.com> 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@us.ibm.com