The itrace "e" option may be followed by a number which has the
following effect for Intel PT:
1 Suppress overflow events
2 Suppress trace data lost events
The values may be combined by bitwise OR'ing them.
Suppressing those errors can be useful for testing and debugging
because they are not due to decoding.
Signed-off-by: Adrian Hunter <[email protected]>
---
tools/perf/Documentation/perf-intel-pt.txt | 7 ++++++-
tools/perf/util/intel-pt.c | 12 ++++++++++++
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-intel-pt.txt b/tools/perf/Documentation/perf-intel-pt.txt
index f4cd49a7fcdb..0fcd8ad897b0 100644
--- a/tools/perf/Documentation/perf-intel-pt.txt
+++ b/tools/perf/Documentation/perf-intel-pt.txt
@@ -871,7 +871,11 @@ Developer Manuals.
Error events show where the decoder lost the trace. Error events
are quite important. Users must know if what they are seeing is a complete
-picture or not.
+picture or not. The "e" option may be followed by a number which has the
+following effect:
+ 1 Suppress overflow events
+ 2 Suppress trace data lost events
+The values may be combined by bitwise OR'ing them.
The "d" option will cause the creation of a file "intel_pt.log" containing all
decoded packets and instructions. Note that this option slows down the decoder
@@ -956,6 +960,7 @@ at the beginning. This is useful to ignore initialization code.
skips the first million instructions.
+
dump option
~~~~~~~~~~~
diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
index 8c441b815d73..a8e8e8acbcc8 100644
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -46,6 +46,9 @@
#define MAX_TIMESTAMP (~0ULL)
+#define INTEL_PT_ERR_SUPPRESS_OVF 1
+#define INTEL_PT_ERR_SUPPRESS_LOST 2
+
struct range {
u64 start;
u64 end;
@@ -1863,6 +1866,15 @@ static int intel_pt_synth_error(struct intel_pt *pt, int code, int cpu,
char msg[MAX_AUXTRACE_ERROR_MSG];
int err;
+ if (pt->synth_opts.error_flags) {
+ if (code == INTEL_PT_ERR_OVR &&
+ pt->synth_opts.error_flags & INTEL_PT_ERR_SUPPRESS_OVF)
+ return 0;
+ if (code == INTEL_PT_ERR_LOST &&
+ pt->synth_opts.error_flags & INTEL_PT_ERR_SUPPRESS_LOST)
+ return 0;
+ }
+
intel_pt__strerror(code, msg, MAX_AUXTRACE_ERROR_MSG);
auxtrace_synth_error(&event.auxtrace_error, PERF_AUXTRACE_ERROR_ITRACE,
--
2.25.1
On Thu, Jul 09, 2020 at 08:36:22PM +0300, Adrian Hunter wrote:
> The itrace "e" option may be followed by a number which has the
> following effect for Intel PT:
> 1 Suppress overflow events
> 2 Suppress trace data lost events
> The values may be combined by bitwise OR'ing them.
>
> Suppressing those errors can be useful for testing and debugging
> because they are not due to decoding.
I suspect it will be useful to more than just decoding and debugging.
But the number is not a nice user interface.
How about e[....]
like e[ol]
Also it's a bit unusual that this disables instead of enables, but ok.
-Andi
On 9/07/20 8:50 pm, Andi Kleen wrote:
> On Thu, Jul 09, 2020 at 08:36:22PM +0300, Adrian Hunter wrote:
>> The itrace "e" option may be followed by a number which has the
>> following effect for Intel PT:
>> 1 Suppress overflow events
>> 2 Suppress trace data lost events
>> The values may be combined by bitwise OR'ing them.
>>
>> Suppressing those errors can be useful for testing and debugging
>> because they are not due to decoding.
>
> I suspect it will be useful to more than just decoding and debugging.
>
> But the number is not a nice user interface.
>
> How about e[....]
>
> like e[ol]
Do you mean literally square-brackets? If you were really unlucky you might
get pathname expansion with that.
>
> Also it's a bit unusual that this disables instead of enables, but ok.
>
> -Andi
>
On 9/07/20 9:13 pm, Adrian Hunter wrote:
> On 9/07/20 8:50 pm, Andi Kleen wrote:
>> On Thu, Jul 09, 2020 at 08:36:22PM +0300, Adrian Hunter wrote:
>>> The itrace "e" option may be followed by a number which has the
>>> following effect for Intel PT:
>>> 1 Suppress overflow events
>>> 2 Suppress trace data lost events
>>> The values may be combined by bitwise OR'ing them.
>>>
>>> Suppressing those errors can be useful for testing and debugging
>>> because they are not due to decoding.
>>
>> I suspect it will be useful to more than just decoding and debugging.
>>
>> But the number is not a nice user interface.
>>
>> How about e[....]
>>
>> like e[ol]
>
> Do you mean literally square-brackets? If you were really unlucky you might
> get pathname expansion with that.
>
>>
>> Also it's a bit unusual that this disables instead of enables, but ok.
What about prefixing each flag with - i.e.
e-o
e-l
e-o-l
> What about prefixing each flag with - i.e.
>
> e-o
> e-l
> e-o-l
I was thinking square brackets, but yes the shell collision is a fair point.
- should work too.
-andi