linux-kernel - Re: [PATCH 00/10] perf, x86: Add northbridge counter support for AMD family 15h

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABPqkBS=QAnoz3-_XgRPoRsUh4GbpHQe+u75dR=pLG2isC8Ccw@mail.gmail.com>
Date:	Wed, 20 Jun 2012 10:36:32 +0200
From:	Stephane Eranian <eranian@...gle.com>
To:	Robert Richter <robert.richter@....com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/10] perf, x86: Add northbridge counter support for AMD
 family 15h

On Tue, Jun 19, 2012 at 8:10 PM, Robert Richter <robert.richter@....com> wrote:
>
> This patch adds northbridge counter support for AMD family 15h cpus.
>
> The NB counter implementation and usage is in the same way as for
> family 10h. Thus a nb event can now be selected as any other
> performance counter event. As for family 10h the kernel selects only
> one NB PMC per node by using the nb constraint handler.
>
> Main part of this patch set is to rework current code in a way that
> bit masks for counters can be used. Also, Intel's fixed counters have
> been moved to Intel only code. This is since AMD nb counters start at
> index 32 which leads to holes in the counter mask and causes conflicts
> with fixed counters.
>

I dont' quite understand the design choice here. In Fam15h, there is a clean
design for the uncore PMU. It has its own distinct set of 4 counters. Unlike
Fam10h, where you program core counters to access the NB counters. So
why not like with Intel uncore, create a separate NB PMU which would
advertise its characteristics? That does not preclude re-using the existing
AMD-specific routines wherever possible. I think the advantage is that
muxing or starting/stopping of the core PMU would not affect uncore and
vice-versa for instance. Wouldn't this also alleviate the problems with
assigning indexes to uncore PMU counters?

> Another major change is the unification of AMD pmus and, where
> possible, a family independent feature check based on cpuid.
>
> It should also be mentioned that nb perfctrs do not support all bits
> in the config value, see patch #10.
>
> -Robert
>
>
>
> Robert Richter (10):
>  perf, amd: Rework northbridge event constraints handler
>  perf, x86: Rework counter reservation code
>  perf, x86: Use bitmasks for generic counters
>  perf, x86: Rename Intel specific macros
>  perf, x86: Move Intel specific code to intel_pmu_init()
>  perf, amd: Unify AMD's generic and family 15h pmus
>  perf, amd: Generalize northbridge constraints code for family 15h
>  perf, amd: Enable northbridge counters on family 15h
>  perf, x86: Improve debug output in check_hw_exists()
>  perf, amd: Check northbridge event config value
>
>  arch/x86/include/asm/cpufeature.h         |    2 +
>  arch/x86/include/asm/kvm_host.h           |    4 +-
>  arch/x86/include/asm/perf_event.h         |   26 ++-
>  arch/x86/kernel/cpu/perf_event.c          |  129 +++++------
>  arch/x86/kernel/cpu/perf_event.h          |    7 +
>  arch/x86/kernel/cpu/perf_event_amd.c      |  368
> +++++++++++++++++------------
>  arch/x86/kernel/cpu/perf_event_intel.c    |   65 +++++-
>  arch/x86/kernel/cpu/perf_event_intel_ds.c |    4 +-
>  arch/x86/kernel/cpu/perf_event_p4.c       |    8 +-
>  arch/x86/kvm/pmu.c                        |   22 +-
>  arch/x86/oprofile/op_model_amd.c          |    4 +-
>  11 files changed, 374 insertions(+), 265 deletions(-)
>
> --
> 1.7.8.4
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/