From: Suzuki K Poulose <email@example.com> To: Mike Leach <firstname.lastname@example.org> Cc: Coresight ML <email@example.com>, linux-arm-kernel <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com>, firstname.lastname@example.org, Al Grant <email@example.com>, Leo Yan <firstname.lastname@example.org>, Mathieu Poirier <email@example.com>, Anshuman Khandual <firstname.lastname@example.org>, email@example.com, James Clark <firstname.lastname@example.org>, Peter Zijlstra <email@example.com>, Will Deacon <firstname.lastname@example.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: <email@example.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 <firstname.lastname@example.org> 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 <email@example.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
next prev parent 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v2 07/10] coresight: trbe: Do not truncate buffer on IRQ' \ /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
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).