Messages in this thread | | | Date | Wed, 22 Dec 2010 12:28:25 -0800 | Subject | Re: [PATCH -v2 2/2] x86, acpi: Parse all SRAT cpu entries even have cpu num limitation | From | Venkatesh Pallipadi <> |
| |
On Tue, Dec 21, 2010 at 10:43 PM, David Rientjes <rientjes@google.com> wrote: > On Mon, 20 Dec 2010, Venkatesh Pallipadi wrote: > >> git bisect seems to narrow this down to the change below. >> >> Thanks, >> Venki >> >> $ git bisect visualize >> commit 50f2d7f682f9c0ed58191d0982fe77888d59d162 >> Author: Nikanth Karthikesan <knikanth@suse.de> >> Date: Thu Sep 30 17:34:10 2010 +0530 >> >> x86, numa: Assign CPUs to nodes in round-robin manner on fake NUMA >> >> commit d9c2d5ac6af87b4491bff107113aaf16f6c2b2d9 "x86, numa: Use near(er) >> online node instead of roundrobin for NUMA" changed NUMA initialization on >> Intel to choose the nearest online node or first node. Fake NUMA would be >> better of with round-robin initialization, instead of the all CPUS on >> first node. Change the choice of first node, back to round-robin. >> >> For testing NUMA kernel behaviour without cpusets and NUMA aware >> applications, it would be better to have cpus in different nodes, rather >> than all in a single node. With cpusets migration of tasks scenarios >> cannot not be tested. >> >> I guess having it round-robin shouldn't affect the use cases for all cpus >> on the first node. >> >> The code comments in arch/x86/mm/numa_64.c:759 indicate that this used to >> be the case, which was changed by commit d9c2d5ac6. It changed from >> roundrobin to nearer or first node. And I couldn't find any reason for >> this change in its changelog. >> >> Signed-off-by: Nikanth Karthikesan <knikanth@suse.de> >> Cc: David Rientjes <rientjes@google.com> >> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> >> > > Peter just merged my NUMA emulation fixes into the x86 tree, could you try > applying Yinghai's series on top of x86/linux-2.6-tip.git#x86/numa and see > if the problem persists? > > On a different topic: Yinghai, do you think you could base your series off > of Tejun's x86_32/x86_64 NUMA unification series since it already > duplicates some of the work? >
Yes. #x86/numa kernel works fine both with and without Yinghai's series. I am assuming those changes are lined up for .38. Is there any specific fix that can make into .37 to fix this regression?
Thanks, Venki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |