Keir Fraser wrote: > On 28/7/08 13:21, "Andre Przywara" wrote: > >> 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... > > Well, fine, but unfortunately the patch breaks ia64 Fixed. > and doesn't even work properly: > - why should NUMA node 0 be the one that overlaps with default DMA memory? Because that is the most common configuration? Do you know of any machine where this is not true? I agree that a dual node machine with 2 gig on each node does not need this patch, but NUMA machines tend to have more memory than this (especially given the current memory costs). I changed the default DMA_BITSIZE to 30 bits, this seems to be a reasonable value. > - a 'large' NUMA node 0 will cause dma_bitsize to be set much larger than > it is currently, thus breaking its original intent. Fixed in the attached patch. It now caps dma_bitsize to at most 1/4 of node0 memory. What about using this patch for Xen 3.3 and work out a more general solution for Xen 3.4? Signed off by: Andre Przywara Based on the patch from: "Yang, Xiaowei" -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 277-84917 ----to satisfy European Law for business letters: AMD Saxony Limited Liability Company & Co. KG, Wilschdorfer Landstr. 101, 01109 Dresden, Germany Register Court Dresden: HRA 4896, General Partner authorized to represent: AMD Saxony LLC (Wilmington, Delaware, US) General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy