Messages in this thread | | | Date | Thu, 28 Feb 2013 20:32:15 -0800 | Subject | Re: sched: CPU #1's llc-sibling CPU #0 is not on the same node! | From | Linus Torvalds <> |
| |
Yingai, Andrew, is this ok with you two?
Linus
On Thu, Feb 28, 2013 at 7:46 PM, Tang Chen <tangchen@cn.fujitsu.com> wrote: > 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@linux-foundation.org> 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 >> >
| |