From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: Memory allocation in NUMA system Date: Mon, 28 Jul 2008 14:21:02 +0200 Message-ID: <488DB9AE.7040305@amd.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com, "Yang, Xiaowei" List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 25/7/08 11:26, "Yang, Xiaowei" wrote: > >>> Indeed the only reason we still have dma_bitsize is to break the >>> select-NUMA-node-first memory allocation search strategy. So tweaking the >>> dma_bitsize approach further to strike the correct NUMA-vs-DMA balance does >>> seem the right thing to do. Feel free to work up a patch. >>> >>> -- Keir >>> >> How about this one? > > Hmmm.. something like that. Let's wait until 3.4 development opens to get > this checked in. Mmh, why not check this in in 3.3? I have noticed this problem already a year ago and was having some other kind of fix for it (which actually prefered nodes over zones): http://lists.xensource.com/archives/html/xen-devel/2007-12/msg00831.html I think this is a somewhat serious issue on NUMA machines, since with the automatic pinning now active (new in 3.3!) many domains will end up with remote memory _all the time_. So I think of this as a bugfix. Actually I have dma_bitsize=30 hardwired in my Grub's menu.lst for some months now... Regards, Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 277-84917