linux-kernel - Re: [PATCH 1/2] perf: Allow non-contiguous AUX buffer pages via PMU capability

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: <20250422141026.GH28953@e132581.arm.com>
Date: Tue, 22 Apr 2025 15:10:26 +0100
From: Leo Yan <leo.yan@....com>
To: Ingo Molnar <mingo@...nel.org>
Cc: James Clark <james.clark@...aro.org>, Yabin Cui <yabinc@...gle.com>,
	coresight@...ts.linaro.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
	Mike Leach <mike.leach@...aro.org>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Namhyung Kim <namhyung@...nel.org>,
	Mark Rutland <mark.rutland@....com>, Jiri Olsa <jolsa@...nel.org>,
	Ian Rogers <irogers@...gle.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Liang Kan <kan.liang@...ux.intel.com>
Subject: Re: [PATCH 1/2] perf: Allow non-contiguous AUX buffer pages via PMU
 capability

On Tue, Apr 22, 2025 at 02:49:54PM +0200, Ingo Molnar wrote:

[...]

> > Hi Yabin,
> > 
> > I was wondering if this is just the opposite of 
> > PERF_PMU_CAP_AUX_NO_SG, and that order 0 should be used by default 
> > for all devices to solve the issue you describe. Because we already 
> > have PERF_PMU_CAP_AUX_NO_SG for devices that need contiguous pages. 
> > Then I found commit 5768402fd9c6 ("perf/ring_buffer: Use high order 
> > allocations for AUX buffers optimistically") that explains that the 
> > current allocation strategy is an optimization.
> > 
> > Your change seems to decide that for certain devices we want to 
> > optimize for fragmentation rather than performance. If these are 
> > rarely used features specifically when looking at performance should 
> > we not continue to optimize for performance? Or at least make it user 
> > configurable?
> 
> So there seems to be 3 categories:
> 
>  - 1) Must have physically contiguous AUX buffers, it's a hardware ABI. 
>       (PERF_PMU_CAP_AUX_NO_SG for Intel BTS and PT.)
> 
>  - 2) Would be nice to have continguous AUX buffers, for a bit more 
>       performance.
> 
>  - 3) Doesn't really care.
> 
> So we do have #1, and it appears Yabin's usecase is #3?

In Yabin's case, the AUX buffer work as a bounce buffer.  The hardware
trace data is copied by a driver from low level's contiguous buffer to
the AUX buffer.

In this case we cannot benefit much from continguous AUX buffers.

Thanks,
Leo