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

[Tang Chen]

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
"movablemem_map=nn[KMG]@ss[KMG]".

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..
>
>                 Linus