From: Suzuki K Poulose <suzuki.poulose@arm.com>
To: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>,
linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org,
linux-kernel@vger.kernel.org, mike.leach@linaro.org,
Al Grant <Al.Grant@arm.com>
Subject: Re: [RFC 09/11] coresight: etm-perf: Disable the path before capturing the trace data
Date: Mon, 14 Dec 2020 10:00:27 +0000 [thread overview]
Message-ID: <b7b0cf92-abfa-ca98-0b55-62e63e4c3457@arm.com> (raw)
In-Reply-To: <20201211203126.GA1921322@xps15>
On 12/11/20 8:31 PM, Mathieu Poirier wrote:
> On Fri, Nov 27, 2020 at 10:32:28AM +0000, Suzuki K Poulose wrote:
>> On 11/10/20 12:45 PM, Anshuman Khandual wrote:
>>> perf handle structure needs to be shared with the TRBE IRQ handler for
>>> capturing trace data and restarting the handle. There is a probability
>>> of an undefined reference based crash when etm event is being stopped
>>> while a TRBE IRQ also getting processed. This happens due the release
>>> of perf handle via perf_aux_output_end(). This stops the sinks via the
>>> link before releasing the handle, which will ensure that a simultaneous
>>> TRBE IRQ could not happen.
>>
>> Or in other words :
>>
>> We now have :
>>
>> update_buffer()
>>
>> perf_aux_output_end(handle)
>>
>> ...
>> disable_path()
>>
>> This is problematic due to various reasons :
>>
>> 1) The semantics of update_buffer() is not clear. i.e, whether it
>> should leave the "sink" "stopped" or "disabled" or "active"
>
> I'm a little confused by the above as the modes that apply here are
> CS_MODE_DISABLED and CS_MODE_PERF, so I'll go with those. Let me know if you
> meant something else.
Sorry, I think it is a bit confusing.
stopped => Sink is in stopped HW state, but the software mode is not changed (i.e, could be
PERF or SYSF)
disabled => Sink is in stopped hw state, the software mode is DISABLED
active => Sink is active and flushing trace, with respective mode (PERF vs SYSFS).
>
> So far ->update_buffer() doesn't touch drvdata->mode and as such it is still set
> to CS_MODE_PERF when the update has completed.
>
>>
>> 2) This breaks the recommended trace collection sequence of
>> "flush" and "stop" from source to the sink for trace collection.
>> i.e, we stop the source now. But don't flush the components
>> from source to sink, rather we stop and flush from the sink.
>> And we flush and stop the path after we have collected the
>> trace data at sink, which is pointless.
>
> The above assesment is correct. Fixing it though has far reaching ramifications
> that go far beyond the scope of this patch.
>
>>
>> 3) For a sink with IRQ handler, if we don't stop the sink with
>> update_buffer(), we could have a situation :
>>
>> update_buffer()
>>
>> perf_aux_outpuf_end(handle) # handle is invalid now
>>
>> -----------------> IRQ -> irq_handler()
>> perf_aux_output_end(handle) # Wrong !
>>
>>
>> disable_path()
>
> That's the picture of the issue I had in my head when looking at the code -
> I'm glad we came to the same conclusion.
>
>>
>> The sysfs mode is fine, as we defer the trace collection to disable_path().
>>
>> The proposed patch is still racy, as we could still hit the problem.
>>
>> So, to avoid all of these situations, I think we should defer the the
>> update_buffer() to sink_ops->disable(), when we have flushed and stopped
>> the all the components upstream and avoid any races with the IRQ
>> handler.
>>
>> i.e,
>>
>> source_ops->stop(csdev);
>>
>> disable_path(handle); // similar to the enable_path
>>
>>
>> sink_ops->disable(csdev, handle)
>> {
>> /* flush & stop */
>>
>> /* collect trace */
>> perf_aux_output_end(handle, size);
>> }
>
> That is one solution. The advantage here is that it takes care of the
> flusing problem you described above. On the flip side it is moving a lot of
> code around, something that is better to do in another set.
>
> Another solution is to disable the TRBE IRQ in ->udpate_buffer(). The ETR does
> the same kind of thing with tmc_flush_and_stop(). I don't know how feasible
> that is but it would be a simple solution for this set. Properly flushing the
> pipeline could be done later. I'm fine with either approach.
Agreed. I think this is reasonable forthis set. i.e, leave the hardware disabled.
We could do the proper solution above as a separate series, to keep the changes
incremental.
Kind regards
Suzuki
next prev parent reply other threads:[~2020-12-14 10:02 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-10 12:44 [RFC 00/11] arm64: coresight: Enable ETE and TRBE Anshuman Khandual
2020-11-10 12:44 ` [RFC 01/11] arm64: Add TRBE definitions Anshuman Khandual
2020-11-10 12:45 ` [RFC 02/11] coresight: etm-perf: Allow an event to use different sinks Anshuman Khandual
2020-11-12 9:21 ` Suzuki K Poulose
2020-11-12 10:37 ` Linu Cherian
2020-11-12 11:09 ` Suzuki K Poulose
2020-11-10 12:45 ` [RFC 03/11] coresight: Do not scan for graph if none is present Anshuman Khandual
2020-11-10 12:45 ` [RFC 04/11] coresight: etm4x: Add support for PE OS lock Anshuman Khandual
2020-11-10 12:45 ` [RFC 05/11] coresight: ete: Add support for sysreg support Anshuman Khandual
2020-11-10 12:45 ` [RFC 06/11] coresight: ete: Detect ETE as one of the supported ETMs Anshuman Khandual
2020-11-14 5:36 ` Tingwei Zhang
2020-11-23 9:56 ` Suzuki K Poulose
2020-11-10 12:45 ` [RFC 07/11] coresight: sink: Add TRBE driver Anshuman Khandual
2020-11-12 10:13 ` Suzuki K Poulose
2020-11-25 5:25 ` Anshuman Khandual
2020-11-14 5:38 ` Tingwei Zhang
2020-11-23 3:51 ` Anshuman Khandual
2020-11-10 12:45 ` [RFC 08/11] coresight: etm-perf: Truncate the perf record if handle has no space Anshuman Khandual
2020-11-10 12:45 ` [RFC 09/11] coresight: etm-perf: Disable the path before capturing the trace data Anshuman Khandual
2020-11-12 9:27 ` Suzuki K Poulose
2020-11-23 6:08 ` Anshuman Khandual
2020-11-23 10:01 ` Suzuki K Poulose
2020-11-27 10:32 ` Suzuki K Poulose
2020-12-11 20:31 ` Mathieu Poirier
2020-12-14 10:00 ` Suzuki K Poulose [this message]
2020-11-10 12:45 ` [RFC 10/11] coresgith: etm-perf: Connect TRBE sink with ETE source Anshuman Khandual
2020-11-12 9:31 ` Suzuki K Poulose
2020-11-23 5:37 ` Anshuman Khandual
2020-12-11 21:31 ` Mathieu Poirier
2020-11-10 12:45 ` [RFC 11/11] dts: bindings: Document device tree binding for Arm TRBE Anshuman Khandual
2020-11-10 18:25 ` [RFC 00/11] arm64: coresight: Enable ETE and TRBE Mathieu Poirier
2020-11-14 5:17 ` Tingwei Zhang
2020-11-16 15:00 ` Mike Leach
2020-11-23 3:40 ` Anshuman Khandual
2020-11-23 12:30 ` Mike Leach
2020-11-23 2:43 ` Anshuman Khandual
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=b7b0cf92-abfa-ca98-0b55-62e63e4c3457@arm.com \
--to=suzuki.poulose@arm.com \
--cc=Al.Grant@arm.com \
--cc=anshuman.khandual@arm.com \
--cc=coresight@lists.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 \
/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).