linux-kernel - Re: [PATCH 1/3 v2] perf/amd/uncore: Prepare L3 thread mask code for Family 19h support

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: <20200318204257.GL20730@hirez.programming.kicks-ass.net>
Date:   Wed, 18 Mar 2020 21:42:57 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Kim Phillips <kim.phillips@....com>
Cc:     Stephane Eranian <eranian@...gle.com>,
        Ingo Molnar <mingo@...nel.org>, Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>, Jiri Olsa <jolsa@...hat.com>,
        Mark Rutland <mark.rutland@....com>,
        Michael Petlan <mpetlan@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>
Subject: Re: [PATCH 1/3 v2] perf/amd/uncore: Prepare L3 thread mask code for
 Family 19h support

On Wed, Mar 18, 2020 at 09:46:41AM -0500, Kim Phillips wrote:

> > But this does not work with the cpumask programmed for the amd_l3 PMU. This mask
> > shows, as it should, one CPU/CCX. So that means that when I do:
> > 
> > $ perf stat -a amd_l3/event=llc_event/
> > 
> > This only collects on the CPUs listed in the cpumask: 0,4,8,12 ....
> > That means that L3 events generated by the other CPUs on the CCX are
> > not monitored.
> > I can easily see the problem by pinning a memory bound program to
> > CPU64, for instance.
> 
> Right, the higher level code calls the driver with a single cpu==0
> call if the perf tool is invoked with a simple -a style system-wide.
> If the tool is invoked with supplemental switches to -a, like -C 0-255,
> and -A, the driver gets called multiple times with all the unique cpu
> values.  The latter is the expected invocation style when measuring
> a benchmark pinned on a subset of cpus, i.e., when evaluating
> the driver, and is the more deterministic behaviour for the driver
> to have, given it cannot tell the difference otherwise.

That seems to suggest it is all horribly broken.