Re: sched: CPU #1's llc-sibling CPU #0 is not on the same node!

From: Tang Chen
Date: Thu Feb 28 2013 - 22:46:51 EST

This is a multi-part message in MIME format.Hi Linus,

Please refer to the attached patch.

This patch everts only the following two patches.

commit 01a178a94e8eaec351b29ee49fbb3d1c124cb7fb
acpi, memory-hotplug: support getting hotplug info from SRAT
commit e8d1955258091e4c92d5a975ebd7fd8a98f5d30f
acpi, memory-hotplug: parse SRAT before memblock is ready

Without these two patches, users can use "movablemem_map=nn[KMG]@ss[KMG]"
correctly, and cause no problem.

And of course, the kernel will work as before if users don't use

I do hope we can keep "movablemem_map=nn[KMG]@ss[KMG]" in 3.9.

We are working on fixing the SRAT problems, and we aims to push SRAT related
patches in 3.10. And we will also improve "movablemem_map=nn[KMG]@ss[KMG]"
functionality consistently in the future.

Thanks. :)

On 03/01/2013 11:13 AM, Linus Torvalds wrote:
On Wed, Feb 27, 2013 at 1:26 PM, Andrew Morton
<akpm@xxxxxxxxxxxxxxxxxxxx> wrote:

So I'm thinking that the best approach here is to revert everything and
then try again for 3.10-rc1. This gives people time to test the code
while it's only in linux-next. (Hint!)

I'd prefer to revert too by now - the bug seems to be known, and
apparently it's not a trivial fix. We're getting close to the end of
the merge window, and it's still being discussed, it clearly wasn't
really fully cooked.

Can we agree on some minimal set of reverts? Can somebody send me a
patch with the revert and the commit explanation for the revert?
Yinghai? Or I can do the reverts too if just the exact set of commits
is clear, but I'd rather get it from somebody who sees and understand
the problem, and can test the state afterwards..