From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: NUMA problem with AMD G34 system Date: Mon, 21 Feb 2011 14:42:59 +0100 Message-ID: <4D626BE3.8030800@amd.com> References: <20110219085932.E08B624258@panix5.panix.com> <4D6226F0.1080007@amd.com> <20110221112958.GA25000@panix.com> <4D6251C8.1020809@amd.com> <20110221132002.GA13858@panix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110221132002.GA13858@panix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Brian Marcotte Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org Brian Marcotte wrote: >> I prepared Xen to handle this situation (nodes without memory) >> before the M-C launch, before that it simply crashed. I agree that >> it is not obvious that you need to populate at least 4 DIMMs per >> CPU. > > I suppose that Xen could arrange the cpu to node mapping such that > the memoryless CPUs were assigned to the "nearest" node making it so > you could benefit from the shared L3 cache. > > I don't know that it's worth anyone's time though. Perhaps a warning > would suffice? I also considered more possible action back then, but found that it is probably not worth the effort, as this kind of configuration was considered kind of bogus. But a warning message sounds like a good idea. > >> Do you have only 4 DIMMs? > > Yes, but I don't expect that to last too long. We find that over the > lifetime of a machine, we max out the RAM slots long before we run out > of CPU. The second CPU is mostly just so we can (eventually) fill all > the RAM slots. It's not a problem to run with one CPU for while. I may > also just pin the domains to particular CPU cores rather than pull the > CPU. Yes, just put all the DIMMs in the blue slots of the first CPU and boot Xen with maxcpus=8. This should give you the best results without much fiddling with the hardware. Regards, Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany