[PATCH v2 5/8] coresight: etm: Add an attribute for updating buffer

[Suzuki K Poulose]

On 10/03/2025 15:50, Leo Yan wrote:
> On Mon, Mar 10, 2025 at 01:29:26PM +0000, Suzuki Kuruppassery Poulose wrote:
>> Hi Leo
>>
>> On 10/03/2025 10:49, Leo Yan wrote:
>>> Add an attribute for updating buffer when the AUX trace is paused.  And
>>> populate the value to the 'update_buf_on_pause' flag during the AUX
>>> setting up.
>>
>> Do we need this attribute in the uAPI ?
> 
> This uAPI allows users to perform AUX pause and resume without the long
> latency caused by copying hardware trace data.
> 
> E.g., a user can specify a large AUX buffer size using option "-m,128M".
> If the buffer is considered large enough to accommodate hardware trace
> data for a small program, the 'update_buf_on_pause' flag can be set to
> false, the copying will be deferred until the end of the perf session.
> 
> I am bias to keep this uAPI.  If you prefer to remove it, I am also
> fine with that.
> 
>> Could we do this by default for
>> sinks without interrupt ? This definitely improves the quality of trace
>> collected for such sinks and the driver can transparently do this.
> 
> How about we dynamically set the default flag in the Perf tool?
> 
> - If users set explictly the 'update_buf_on_pause' flag, then the
>    setting will be respected.
> - If users don't set the flag, perf tool detects it is TRBE sinks,
>    then it can set 'update_buf_on_pause' flag as false.

Not really possible. There could be systems with mixed sinks. e.g.  TRBE
for some CPU and ETR for others (say due to a non-functioning TRBE).

> - If users don't set the flag, perf tool detects it is ETF/ETB/ETR
>    sinks, it sets the flag as true.

And in the cases above, perf event cannot run on all the CPUs, because
some sinks don't support it.

Why do we need a flag, when the effect is not user (read, perf decoder)
  visible and at the same time improves some scenarios (read non-TRBE 
cases) ?

I would say, let the driver always update on pause, depending on the
sink.

Suzuki


> 
> Thanks,
> Leo