Li-Ta Lo wrote:
> On Tue, 2007-04-24 at 21:49 +0200, Bert Wesarg wrote:
>> Hi,
>>
>> Li-Ta Lo wrote:
>>> Hi,
>>>
>>> My dual Xeon desktop with SMT (1 core, 2 threads) is reported by the
>>> kernel in a very strange way. The kernel thinks the first physical
>>> processor as socket 0 but the second physical processor as socket
>>> 3. There is no socket 1 or 2 either reported by /proc/cpuinfo or
>>> /sys. This breaks the for loop code counting max sockets in
>>> load_cache() as it assumes the sockets # are consecutive (and
>>> allocating memory for non-existence sockets). As a consequence,
>>> the total number of socket is incorrect neither.
>>>
>>> I don't know if we are going to see nonconsecutive processor
>>> id, core id or thread id reported by kernel in reality.
>>>
>>> I attached the /proc/cpuinfo and /sys for your reference.
>> Hmm, but the /proc/cpuinfo shows for the physical id 0 for first two cpus
>> and 3 for the last two. I don't know why.
>>
>> processor : 0
>> physical id : 0
>> processor : 1
>> physical id : 0
>> processor : 2
>> physical id : 3
>> processor : 3
>> physical id : 3
>>
>
> This is exactly what I am talking about. Process 2 and 3 are considered
> on physical id (socket?) 3. In this case, the max_socket !=
> number_of_sockets.
Yeah, but nobody talked ever about number of sockets, only max number of
socket id, and this is totally correct here. At my first look over the
code, I thought the whole time: "why do they only return max_core, and not
max_core + 1", but here you have the reason.
>
> Oh, I think this may actually be how it is reported by the BIOS via ACPI
> tables.
Just curious, what kernel version run on this machine? Maybe they have
fixed it.
>
> Ollie
Bert
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}