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

[Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>]

Hi Yinghai,

2013/02/26 15:57, Yinghai Lu wrote:
> On Mon, Feb 25, 2013 at 10:09 PM, Tang Chen <tangchen@cn.fujitsu.com> wrote:
>> On 02/26/2013 12:51 PM, Martin Bligh wrote:
>>>>
>>>> Do you mean we can remove numaq x86 32bit code now?
>>>
>>>
>>> Wouldn't bother me at all. The machine is from 1995, end of life c. 2000?
>>> Was useful in the early days of getting NUMA up and running on Linux,
>>> but is now too old to be a museum piece, really.
>>>
>>> M.
>>>
>>
>> Hi Martin, Yinghai,
>>
>> It was me that I failed to make numa_init() fall back path working, and
>> forgot
>> to call early_parse_srat in ia64. Sorry for the breaking of other platform.
>> :)
>>
>> So now, is Yinghai's patch enough for this problem ?
>> Or we can encapsulate the following clear up work into one function ?
>>
>>
>> +               for (i = 0; i < MAX_LOCAL_APIC; i++)
>> +                       set_apicid_to_node(i, NUMA_NO_NODE);
>> +               nodes_clear(numa_nodes_parsed);
>> +               memset(&numa_meminfo, 0, sizeof(numa_meminfo));
>>
>>
>
> That is temporary workaround and your patch and this workaround make
> x86 acpi numa init too messy.
>
> I don't see the point to hack SRAT to make memory hotplug working.
>
> Do you guys check and use PMTT in ACPI spec instead?

I read PMTT specification in ACPI spec revision 5.0. But this table
does not have hotpluggable information. So we cannot know which memory
device can hotplug from this table.

Thanks,
Yasuaki Ishimatsu

>
> Yinghai
> --
> 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/
>