linux-kernel - Re: [PATCH v6 06/12] perf/x86/amd: add AMD branch sampling period adjustment

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: <YgPedIWUiPIzF8OW@hirez.programming.kicks-ass.net>
Date:   Wed, 9 Feb 2022 16:32:04 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Stephane Eranian <eranian@...gle.com>
Cc:     linux-kernel@...r.kernel.org, kim.phillips@....com,
        acme@...hat.com, jolsa@...hat.com, songliubraving@...com
Subject: Re: [PATCH v6 06/12] perf/x86/amd: add AMD branch sampling period
 adjustment

On Tue, Feb 08, 2022 at 01:16:31PM -0800, Stephane Eranian wrote:
> Add code to adjust the sampling event period when used with the Branch
> Sampling feature (BRS). Given the depth of the BRS (16), the period is
> reduced by that depth such that in the best case scenario, BRS saturates at
> the desired sampling period. In practice, though, the processor may execute
> more branches. Given a desired period P and a depth D, the kernel programs
> the actual period at P - D. After P occurrences of the sampling event, the
> counter overflows. It then may take X branches (skid) before the NMI is
> caught and held by the hardware and BRS activates. Then, after D branches,
> BRS saturates and the NMI is delivered.  With no skid, the effective period
> would be (P - D) + D = P. In practice, however, it will likely be (P - D) +
> X + D. There is no way to eliminate X or predict X.
> 
> Signed-off-by: Stephane Eranian <eranian@...gle.com>
> ---
>  arch/x86/events/core.c       |  7 +++++++
>  arch/x86/events/perf_event.h | 12 ++++++++++++
>  2 files changed, 19 insertions(+)
> 
> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> index c2a890caeb0a..ed285f640efe 100644
> --- a/arch/x86/events/core.c
> +++ b/arch/x86/events/core.c
> @@ -1374,6 +1374,13 @@ int x86_perf_event_set_period(struct perf_event *event)
>  	    x86_pmu.set_topdown_event_period)
>  		return x86_pmu.set_topdown_event_period(event);
>  
> +	/*
> +	 * decrease period by the depth of the BRS feature to get
> +	 * the last N taken branches and approximate the desired period
> +	 */
> +	if (has_branch_stack(event))
> +		period = amd_brs_adjust_period(period);
> +
>  	/*
>  	 * If we are way outside a reasonable range then just skip forward:
>  	 */
> diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
> index 3485a4cf0241..25b037b571e4 100644
> --- a/arch/x86/events/perf_event.h
> +++ b/arch/x86/events/perf_event.h
> @@ -1263,6 +1263,14 @@ static inline bool amd_brs_active(void)
>  	return cpuc->brs_active;
>  }
>  
> +static inline s64 amd_brs_adjust_period(s64 period)
> +{
> +	if (period > x86_pmu.lbr_nr)
> +		return period - x86_pmu.lbr_nr;
> +
> +	return period;
> +}

This makes no sense to me without also enforcing that the event is in
fact that branch retired thing.