lkml.org 
[lkml]   [2014]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RFC: /proc/cpuinfo confusion with AMD processors
On Mon, Jun 30, 2014 at 09:29:05AM -0400, Prarit Bhargava wrote:
> Yes, I get that. But this doesn't uniquely identify *which* processor
> it is.

What do you mean, which processor it is? You want to know which
processor on the motherboard, physically? When you look at the mobo and
if all is enumerated regularly and you have a, say, two socket system
with the processors above, to be able to say that processor 31 is the
16th core on the second node on the motherboard? Something like that?

> Admins load systems relative to nodes, and look at /proc/cpuinfo as a
> "known" place to get that info. At the end of the day I'd like to be
> able to human-read /proc/cpuinfo and get the correct data out of it
> without jumping through hoops

What correct data? All that's there is correct AFAICT. Give an example
of what you want to do?

> to get processor location information. I can, in theory, use the
> initial apicid and the apicid to map everything out ... but I
> shouldn't have to. /proc/cpuinfo provides an easy look up for this
> data for Intel; why not for AMD?

What does it show on Intel that's clear there and that's puzzling you on
AMD?

> Additionally the turbostat utility, for example, is broken because of
> this lack of info. It assumes that /sys/../cpu/cpuX/topology/core_id
> is *per package* when on AMD systems it is reported as per node.

The turbostat utility might need some testing and fixing on AMD. If you
can get some resources to do that I think everyone will profit from it.

> I read that exact same thing somewhere else. The argument you're
> making is that it might be broken for some other reason. It already is
> completely misleading and utterly useless in the above case. A simple
> test patch to arch/x86/kernel/cpu/proc.c shows that including the
> information above is trivial. Adding it /sys/.../cpu/cpuX/topology is
> a little bit more difficult.

And I'm still saying that that information - albeit being trivial to
add - might be lying on some system doing renumbering. So, again: what
exactly do you want to be able to figure out from /proc/cpuinfo and what
is puzzling you? Give concrete examples please...

Thanks.

--
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--


\
 
 \ /
  Last update: 2014-06-30 16:21    [W:0.086 / U:32.960 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site