On 12/12/2025 17:27, Leo Yan wrote:
On Fri, Dec 12, 2025 at 04:50:52PM +0200, James Clark wrote:
[...]
The trace can be stopped on Fill mode (stop on wrap) or Stop on trigger, so it is not (only) about buffer error. In these cases, even though the trace unit is stopped, the buffer may still have space available, tracing can be directly re-enabled in interrupt handler, thus the COLLISION/PARTIAL flags are better choices.
I suppose this is the bit that I don't understand. If there is space left then why is the stop hit at all?
For instance, the buffer becomes empty in the middle:
+----------------------------+ |$$$$$$$| |$$$$$$$| +----------------------------+ ` base `wptr `limitIn this case, the trace unit stops when it reaches the limit. Meanwhile, the tool might have already read out the old trace data so we will get some free space, thus no need to set TRUNCATED flag.
Hmmm I see, I still think that means that Perf is being too slow and disabling the event wouldn't be that bad.
Also isn't there a very small chance to hit this? I'm wondering if you ever saw PARTIAL flags in practice?
I think the following all have to be true:
* 3 out of 4 sections were full on the last interrupt * Perf hadn't managed to finish reading even 1 section in that time * The last section fills up * Perf had managed to finish reading 1 section between the time of the previous interrupt and the hard stop
There would have to be quite a high variability in read speed to make that possible. Maybe it happens and it's worthwhile optimizing for. The comments could explain it better if we do decide to keep it.