linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Suzuki K Poulose <suzuki.poulose@arm.com>
To: Mike Leach <mike.leach@linaro.org>
Cc: Coresight ML <coresight@lists.linaro.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	tamas.zsoldos@arm.com, Al Grant <al.grant@arm.com>,
	Leo Yan <leo.yan@linaro.org>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	jinlmao@qti.qualcomm.com, James Clark <james.clark@arm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Will Deacon <will@kernel.org>
Subject: Re: [PATCH v2 07/10] coresight: trbe: Do not truncate buffer on IRQ
Date: Tue, 27 Jul 2021 14:06:33 +0100	[thread overview]
Message-ID: <278117cd-677d-c1be-b1e3-ea2a8825fcb1@arm.com> (raw)
In-Reply-To: <CAJ9a7VgEfx=BREdo23EW60c8W-FXNPrkDjAbiXA-wOi-cm_D8A@mail.gmail.com>

On 27/07/2021 11:46, Mike Leach wrote:
> HI Suzuki,
> 
> On Mon, 26 Jul 2021 at 17:01, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>>
>> Hi Mike,
>>
>> On 26/07/2021 13:34, Mike Leach wrote:
>>> Hi Suzuki,
>>>
>>> On Fri, 23 Jul 2021 at 13:46, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>>>>
>>>> The TRBE driver marks the AUX buffer as TRUNCATED when we get an IRQ
>>>> on FILL event. This has rather unwanted side-effect of the event
>>>> being disabled when there may be more space in the ring buffer.
>>>>
>>>> So, instead of TRUNCATE we need a different flag to indicate
>>>> that the trace may have lost a few bytes (i.e from the point of
>>>> generating the FILL event until the IRQ is consumed). Anyways, the
>>>> userspace must use the size from RECORD_AUX headers to restrict
>>>> the "trace" decoding.
>>>>
>>>> Using PARTIAL flag causes the perf tool to generate the
>>>> following warning:
>>>>
>>>>     Warning:
>>>>     AUX data had gaps in it XX times out of YY!
>>>>
>>>>     Are you running a KVM guest in the background?
>>>>
>>>> which is pointlessly scary for a user. The other remaining options
>>>> are :
>>>>     - COLLISION - Use by SPE to indicate samples collided
>>>>     - Add a new flag - Specifically for CoreSight, doesn't sound
>>>>       so good, if we can re-use something.
>>>>
>>>
>>> What is the user visible behaviour when using COLLISION?
>>
>> If you meant a Warning from the perf tool (similar to TRUNCATE or
>> PARTIAL), the answer is none. We could add one in the perf tool
>> if you think this is necessary.
>>
> 
> I do - the problem is that we have replaced a visible warning with a
> silent failure.
> 
> While we agree that the side effects of TRUNCATE mean it unfeasible as
> a solution here - at least the PARTIAL message does give some
> indication.
> The average perf user is going to rely on the output from the tool -
> if there is no warning they will assume all is good, but they have
> possible non-contiguous trace and no indication of such.
> 
> Since we are using a collision flag  in a particular context - i.e.
> coresight trace - we have the chance to provide an appropriate message
> for this context.
> 
>>> The TRUNCATE warning is at least accurate - even if the KVM thing is
>>> something of a red herring.
>>
> 
> Sorry - I meant PARTIAL here - but the comment stands otherwise.
> 
>>
>>> It is easier to explain a "scary" warning, than try to debug someones
>>> problems if perf is silent or misleading when using the COLLISION
>>> flag.
>>
>> The RECORD_AUX still has this flag. So, if someone really wanted to
>> know how many times the TRBE fired the IRQ and thus potentially lost a
>> few bytes of the trace, they could always look at this.
>>
> 
> They could - but how would they know that they needed to - what
> indicators would they have that the trace was not continuous?
> The point of the perf tool is that it presents an accurate picture to
> the user, based on the data collected. Most users aren't going to
> start digging into the intricacies of the perf data file formats and
> nor should they have to.
> 
>> Definitely this is not something similar to "TRUNCATED", which we
>> realized the hard way, nor the PARTIAL. But the perf tool could
>> report something similar. Please remember that the perf tool always
>> uses the "size" field from the RECORD_AUX to limit the trace decoding.
>>
>> So, I am not sure how this could create new problems.
>>
> 
> There is no issue with decode - but if a user is investigating a
> problem using trace, they need to be aware that some trace might be
> dropped.
> That way they can take mitigating action.

Agreed. This is something that can be done by the perf tool.

Kind regards
Suzuki

  reply	other threads:[~2021-07-27 13:06 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-23 12:46 [PATCH v2 00/10] coresight: TRBE and Self-Hosted trace fixes Suzuki K Poulose
2021-07-23 12:46 ` [PATCH v2 01/10] coresight: etm4x: Save restore TRFCR_EL1 Suzuki K Poulose
2021-07-30  3:05   ` Anshuman Khandual
2021-07-23 12:46 ` [PATCH v2 02/10] coresight: etm4x: Use Trace Filtering controls dynamically Suzuki K Poulose
2021-07-30  3:48   ` Anshuman Khandual
2021-07-30 11:29     ` Suzuki K Poulose
2021-07-23 12:46 ` [PATCH v2 03/10] coresight: etm-pmu: Ensure the AUX handle is valid Suzuki K Poulose
2021-07-30  4:14   ` Anshuman Khandual
2021-07-23 12:46 ` [PATCH v2 04/10] coresight: trbe: Ensure the format flag is set on truncation Suzuki K Poulose
2021-07-30  4:26   ` Anshuman Khandual
2021-07-30 11:37     ` Suzuki K Poulose
2021-07-23 12:46 ` [PATCH v2 05/10] coresight: trbe: Drop duplicate TRUNCATE flags Suzuki K Poulose
2021-07-30  4:47   ` Anshuman Khandual
2021-07-30 12:58     ` Suzuki K Poulose
2021-07-23 12:46 ` [PATCH v2 06/10] coresight: trbe: Fix handling of spurious interrupts Suzuki K Poulose
2021-07-30  5:15   ` Anshuman Khandual
2021-07-30 12:57     ` Suzuki K Poulose
2021-07-23 12:46 ` [PATCH v2 07/10] coresight: trbe: Do not truncate buffer on IRQ Suzuki K Poulose
2021-07-26 12:34   ` Mike Leach
2021-07-26 16:01     ` Suzuki K Poulose
2021-07-27 10:46       ` Mike Leach
2021-07-27 13:06         ` Suzuki K Poulose [this message]
2021-07-28  9:25           ` Suzuki K Poulose
2021-07-23 12:46 ` [PATCH v2 08/10] coresight: trbe: Unify the enabling sequence Suzuki K Poulose
2021-07-30  5:40   ` Anshuman Khandual
2021-07-23 12:46 ` [PATCH v2 09/10] coresight: trbe: End the AUX handle on truncation Suzuki K Poulose
2021-07-30  5:54   ` Anshuman Khandual
2021-07-23 12:46 ` [PATCH v2 10/10] coresight: trbe: Prohibit trace before disabling TRBE Suzuki K Poulose
2021-07-30  6:58   ` Anshuman Khandual
2021-07-23 13:45 ` [PATCH v2 00/10] coresight: TRBE and Self-Hosted trace fixes Suzuki K Poulose

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=278117cd-677d-c1be-b1e3-ea2a8825fcb1@arm.com \
    --to=suzuki.poulose@arm.com \
    --cc=al.grant@arm.com \
    --cc=anshuman.khandual@arm.com \
    --cc=coresight@lists.linaro.org \
    --cc=james.clark@arm.com \
    --cc=jinlmao@qti.qualcomm.com \
    --cc=leo.yan@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=mike.leach@linaro.org \
    --cc=peterz@infradead.org \
    --cc=tamas.zsoldos@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).