public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Prarit Bhargava <prarit@redhat.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: RFC: /proc/cpuinfo confusion with AMD processors
Date: Mon, 30 Jun 2014 15:38:03 +0200	[thread overview]
Message-ID: <20140630133803.GE4766@pd.tnic> (raw)
In-Reply-To: <53B16621.50505@redhat.com>

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

  reply	other threads:[~2014-06-30 13:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-30 12:50 RFC: /proc/cpuinfo confusion with AMD processors Prarit Bhargava
2014-06-30 13:13 ` Borislav Petkov
2014-06-30 13:29   ` Prarit Bhargava
2014-06-30 13:38     ` Borislav Petkov [this message]
2014-06-30 14:07       ` Prarit Bhargava
2014-06-30 18:27         ` Borislav Petkov
2014-07-02 22:01       ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140630133803.GE4766@pd.tnic \
    --to=bp@alien8.de \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prarit@redhat.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox