linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Sandipan Das <sandipan.das@amd.com>,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	x86@kernel.org
Cc: peterz@infradead.org, mingo@redhat.com, acme@kernel.org,
	mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
	jolsa@kernel.org, namhyung@kernel.org, irogers@google.com,
	adrian.hunter@intel.com, bp@alien8.de,
	dave.hansen@linux.intel.com, hpa@zytor.com, eranian@google.com,
	ananth.narayan@amd.com, ravi.bangoria@amd.com,
	santosh.shukla@amd.com, sandipan.das@amd.com
Subject: Re: [PATCH 3/6] x86/cpuid: Add smp helper
Date: Wed, 19 Jul 2023 09:29:10 +0200	[thread overview]
Message-ID: <87v8egwe9l.ffs@tglx> (raw)
In-Reply-To: <827723d8f506411700c68bccc5072ec8d918d2de.1689748843.git.sandipan.das@amd.com>

On Wed, Jul 19 2023 at 12:25, Sandipan Das wrote:
> Depending on which CPU the CPUID instruction is executed, some leaves
> can report different values. There are cases where it may be required
> to know all possible values.
>
> E.g. for AMD Zen 4 processors, the ActiveUmcMask field from leaf
> 0x80000022 ECX, which provides a way to determine the active memory
> controllers, can have different masks on CPUs belonging to different
> sockets as each socket can follow a different DIMM population scheme.
> Each memory channel is assigned a memory controller (UMC) and if no
> DIMMs are attached to a channel, the corresponding memory controller
> is inactive. There are performance monitoring counters exclusive to
> each memory controller which need to be represented under separate
> PMUs. So, it will be necessary to know the active memory controllers
> on each socket during the initialization of the UMC PMUs irrespective
> of where the uncore driver's module init runs.
>
> Add a new helper that executes CPUID on a particular CPU and returns
> the EAX, EBX, ECX and EDX values.

NAK.

This madness has to stop. The correct thing is to parse the information
in CPUID at the point where the CPU comes online and store it for easy
consumption.

I'm in the process of reworking the CPUID and topology evaluation and
that's where these things need to be stored. I'm still fighting some
nightmares with the already existing mess.

Look at the mess people created over time here:

     https://lore.kernel.org/lkml/20230717223049.327865981@linutronix.de

No need to add more insanities to it. IOW, this has to wait for a week
or two until I settled the remaining issues.

Thanks

        tglx

  parent reply	other threads:[~2023-07-19  7:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-19  6:55 [PATCH 0/6] perf/x86/amd: Add memory controller events Sandipan Das
2023-07-19  6:55 ` [PATCH 1/6] perf/x86/amd/uncore: Refactor uncore management Sandipan Das
2023-07-19  6:55 ` [PATCH 2/6] perf/x86/amd/uncore: Use rdmsr if rdpmc is unavailable Sandipan Das
2023-07-19  6:55 ` [PATCH 3/6] x86/cpuid: Add smp helper Sandipan Das
2023-07-19  7:28   ` Peter Zijlstra
2023-07-19  7:37     ` Sandipan Das
2023-07-19  7:29   ` Thomas Gleixner [this message]
2023-07-19  7:35     ` Sandipan Das
2023-07-19 11:50     ` Thomas Gleixner
2023-07-19 11:59       ` Sandipan Das
2023-07-19  6:55 ` [PATCH 4/6] perf/x86/amd/uncore: Add group exclusivity Sandipan Das
2023-07-19  6:55 ` [PATCH 5/6] perf/x86/amd/uncore: Add memory controller support Sandipan Das
2023-07-19  6:55 ` [PATCH 6/6] perf vendor events amd: Add Zen 4 memory controller events Sandipan Das
2023-07-19 16:12   ` Ian Rogers
2023-07-20  5:23     ` Sandipan Das
2023-07-20 15:50       ` Ian Rogers
2023-07-21  5:15         ` Sandipan Das

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=87v8egwe9l.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=ananth.narayan@amd.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=eranian@google.com \
    --cc=hpa@zytor.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=ravi.bangoria@amd.com \
    --cc=sandipan.das@amd.com \
    --cc=santosh.shukla@amd.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;
as well as URLs for NNTP newsgroup(s).