[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3002ad3a-2ce1-3414-f511-f30370ec0488@intel.com>
Date: Thu, 9 Jul 2020 21:22:16 +0300
From: Adrian Hunter <adrian.hunter@...el.com>
To: Andi Kleen <ak@...ux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>,
Jiri Olsa <jolsa@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 05/11] perf intel-pt: Use itrace error flags to suppress
some errors
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
Powered by blists - more mailing lists