[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] numa=on broken
* 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |