From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Leo Yan <leo.yan@linaro.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Coresight ML <coresight@lists.linaro.org>,
linux-kernel@vger.kernel.org, Namhyung Kim <namhyung@kernel.org>,
Robert Walker <robert.walker@arm.com>,
Jiri Olsa <jolsa@redhat.com>,
linux-arm-kernel@lists.infradead.org,
Mike Leach <mike.leach@linaro.org>
Subject: Re: [PATCH v3 6/8] perf cs-etm: Treat NO_SYNC element as trace discontinuity
Date: Thu, 13 Dec 2018 09:41:54 -0300 [thread overview]
Message-ID: <20181213124154.GF21027@kernel.org> (raw)
In-Reply-To: <20181213123854.GE21027@kernel.org>
Em Thu, Dec 13, 2018 at 09:38:54AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Dec 11, 2018 at 03:38:26PM +0800, Leo Yan escreveu:
> > CoreSight tracer driver might insert barrier packet between different
> > buffers, thus the decoder can spot the boundaries based on the barrier
> > packet; the decoder is possible to hit a barrier packet and emit a
> > NO_SYNC element, then the decoder will find a periodic synchronisation
> > point inside that next trace block that starts trace again but does not
> > have the TRACE_ON element as indicator - usually because this block of
> > trace has wrapped the buffer so we have lost the original point that
> > trace was enabled.
> >
> > In upper case, it results in the trace stream only inserts the
> > OCSD_GEN_TRC_ELEM_NO_SYNC element in the middle of tracing stream, but
> > we don't handle NO_SYNC element properly and at the end users miss to
> > see the info for trace discontinuity.
>
>
> "In upper case"? Maybe:
>
> In the former case it causes the insertion of a OCSD_GEN_TRC_ELEM_NO_SYNC
> in the middle of the the tracing stream, but as we were npt handling the
> NO_SYNC element properly which ends up making users miss the
> discontinuity indication"?
> > Though OCSD_GEN_TRC_ELEM_NO_SYNC is different from CS_ETM_TRACE_ON when
> > output from the decoder, but both of them indicate the trace data is
>
> can we remove the "but" and "of them" (redundant) above?
>
> > discontinuous; this patch treats OCSD_GEN_TRC_ELEM_NO_SYNC as trace
> a
> > discontinuity and generates CS_ETM_DISCONTINUITY packet for it, so
> > cs-etm can handle discontinuity for this case, finally it saves the last
> it (way too many "discontinuity")
> > trace data for previous trace block and restart samples for new block.
I've tentatively done those changes (and a few more) in my local branch,
resulting in the wording below, plese let me know if you are ok with it:
commit 148068b45fe2e93b19c06cfc1140ea12ca72eb59
Author: Leo Yan <leo.yan@linaro.org>
Date: Tue Dec 11 15:38:26 2018 +0800
perf cs-etm: Treat NO_SYNC element as trace discontinuity
The CoreSight tracer driver might insert a barrier packets between
different buffers, thus the decoder can spot the boundaries based on the
barrier packet; it is possible for the decoder to hit a barrier packet
and emit a NO_SYNC element, then the decoder will find a periodic
synchronisation point inside that next trace block that starts the trace
again but does not have the TRACE_ON element as indicator - usually
because this trace block has wrapped the buffer so we have lost the
original point when the trace was enabled.
In the first case it causes the insertion of a OCSD_GEN_TRC_ELEM_NO_SYNC
in the middle of the the tracing stream, but as we were npt handling the
NO_SYNC element properly which ends up making users miss the
discontinuity indication"?
Though OCSD_GEN_TRC_ELEM_NO_SYNC is different from CS_ETM_TRACE_ON when
output from the decoder, both indicate that the trace data is
discontinuous; this patch treats OCSD_GEN_TRC_ELEM_NO_SYNC as a trace
discontinuity and generates a CS_ETM_DISCONTINUITY packet for it, so
cs-etm can handle the discontinuity for this case, finally it saves the
last trace data for the previous trace block and restart samples for the
new block.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Robert Walker <robert.walker@arm.com>
Cc: coresight ml <coresight@lists.linaro.org>
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1544513908-16805-7-git-send-email-leo.yan@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index 1039f364f4cc..bee026e76a4c 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -410,7 +410,6 @@ static ocsd_datapath_resp_t cs_etm_decoder__gen_trace_elem_printer(
case OCSD_GEN_TRC_ELEM_UNKNOWN:
break;
case OCSD_GEN_TRC_ELEM_NO_SYNC:
- break;
case OCSD_GEN_TRC_ELEM_TRACE_ON:
resp = cs_etm_decoder__buffer_discontinuity(decoder,
trace_chan_id);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Leo Yan <leo.yan@linaro.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Coresight ML <coresight@lists.linaro.org>,
Mike Leach <mike.leach@linaro.org>,
Robert Walker <robert.walker@arm.com>
Subject: Re: [PATCH v3 6/8] perf cs-etm: Treat NO_SYNC element as trace discontinuity
Date: Thu, 13 Dec 2018 09:41:54 -0300 [thread overview]
Message-ID: <20181213124154.GF21027@kernel.org> (raw)
In-Reply-To: <20181213123854.GE21027@kernel.org>
Em Thu, Dec 13, 2018 at 09:38:54AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Dec 11, 2018 at 03:38:26PM +0800, Leo Yan escreveu:
> > CoreSight tracer driver might insert barrier packet between different
> > buffers, thus the decoder can spot the boundaries based on the barrier
> > packet; the decoder is possible to hit a barrier packet and emit a
> > NO_SYNC element, then the decoder will find a periodic synchronisation
> > point inside that next trace block that starts trace again but does not
> > have the TRACE_ON element as indicator - usually because this block of
> > trace has wrapped the buffer so we have lost the original point that
> > trace was enabled.
> >
> > In upper case, it results in the trace stream only inserts the
> > OCSD_GEN_TRC_ELEM_NO_SYNC element in the middle of tracing stream, but
> > we don't handle NO_SYNC element properly and at the end users miss to
> > see the info for trace discontinuity.
>
>
> "In upper case"? Maybe:
>
> In the former case it causes the insertion of a OCSD_GEN_TRC_ELEM_NO_SYNC
> in the middle of the the tracing stream, but as we were npt handling the
> NO_SYNC element properly which ends up making users miss the
> discontinuity indication"?
> > Though OCSD_GEN_TRC_ELEM_NO_SYNC is different from CS_ETM_TRACE_ON when
> > output from the decoder, but both of them indicate the trace data is
>
> can we remove the "but" and "of them" (redundant) above?
>
> > discontinuous; this patch treats OCSD_GEN_TRC_ELEM_NO_SYNC as trace
> a
> > discontinuity and generates CS_ETM_DISCONTINUITY packet for it, so
> > cs-etm can handle discontinuity for this case, finally it saves the last
> it (way too many "discontinuity")
> > trace data for previous trace block and restart samples for new block.
I've tentatively done those changes (and a few more) in my local branch,
resulting in the wording below, plese let me know if you are ok with it:
commit 148068b45fe2e93b19c06cfc1140ea12ca72eb59
Author: Leo Yan <leo.yan@linaro.org>
Date: Tue Dec 11 15:38:26 2018 +0800
perf cs-etm: Treat NO_SYNC element as trace discontinuity
The CoreSight tracer driver might insert a barrier packets between
different buffers, thus the decoder can spot the boundaries based on the
barrier packet; it is possible for the decoder to hit a barrier packet
and emit a NO_SYNC element, then the decoder will find a periodic
synchronisation point inside that next trace block that starts the trace
again but does not have the TRACE_ON element as indicator - usually
because this trace block has wrapped the buffer so we have lost the
original point when the trace was enabled.
In the first case it causes the insertion of a OCSD_GEN_TRC_ELEM_NO_SYNC
in the middle of the the tracing stream, but as we were npt handling the
NO_SYNC element properly which ends up making users miss the
discontinuity indication"?
Though OCSD_GEN_TRC_ELEM_NO_SYNC is different from CS_ETM_TRACE_ON when
output from the decoder, both indicate that the trace data is
discontinuous; this patch treats OCSD_GEN_TRC_ELEM_NO_SYNC as a trace
discontinuity and generates a CS_ETM_DISCONTINUITY packet for it, so
cs-etm can handle the discontinuity for this case, finally it saves the
last trace data for the previous trace block and restart samples for the
new block.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Robert Walker <robert.walker@arm.com>
Cc: coresight ml <coresight@lists.linaro.org>
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1544513908-16805-7-git-send-email-leo.yan@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index 1039f364f4cc..bee026e76a4c 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -410,7 +410,6 @@ static ocsd_datapath_resp_t cs_etm_decoder__gen_trace_elem_printer(
case OCSD_GEN_TRC_ELEM_UNKNOWN:
break;
case OCSD_GEN_TRC_ELEM_NO_SYNC:
- break;
case OCSD_GEN_TRC_ELEM_TRACE_ON:
resp = cs_etm_decoder__buffer_discontinuity(decoder,
trace_chan_id);
next prev parent reply other threads:[~2018-12-13 12:42 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-11 7:38 [PATCH v3 0/8] perf cs-etm: Correct packets handling Leo Yan
2018-12-11 7:38 ` Leo Yan
2018-12-11 7:38 ` [PATCH v3 1/8] perf cs-etm: Correct packets swapping in cs_etm__flush() Leo Yan
2018-12-11 7:38 ` Leo Yan
2018-12-20 18:12 ` [tip:perf/core] " tip-bot for Leo Yan
2018-12-11 7:38 ` [PATCH v3 2/8] perf cs-etm: Avoid stale branch samples when flush packet Leo Yan
2018-12-11 7:38 ` Leo Yan
2018-12-20 18:12 ` [tip:perf/core] " tip-bot for Leo Yan
2018-12-11 7:38 ` [PATCH v3 3/8] perf cs-etm: Remove unused 'trace_on' in cs_etm_decoder Leo Yan
2018-12-11 7:38 ` Leo Yan
2018-12-12 18:41 ` Mathieu Poirier
2018-12-12 18:41 ` Mathieu Poirier
2018-12-20 18:13 ` [tip:perf/core] " tip-bot for Leo Yan
2018-12-11 7:38 ` [PATCH v3 4/8] perf cs-etm: Refactor enumeration cs_etm_sample_type Leo Yan
2018-12-11 7:38 ` Leo Yan
2018-12-12 18:41 ` Mathieu Poirier
2018-12-12 18:41 ` Mathieu Poirier
2018-12-20 18:14 ` [tip:perf/core] " tip-bot for Leo Yan
2018-12-11 7:38 ` [PATCH v3 5/8] perf cs-etm: Rename CS_ETM_TRACE_ON to CS_ETM_DISCONTINUITY Leo Yan
2018-12-11 7:38 ` Leo Yan
2018-12-20 18:14 ` [tip:perf/core] " tip-bot for Leo Yan
2018-12-11 7:38 ` [PATCH v3 6/8] perf cs-etm: Treat NO_SYNC element as trace discontinuity Leo Yan
2018-12-11 7:38 ` Leo Yan
2018-12-13 12:38 ` Arnaldo Carvalho de Melo
2018-12-13 12:38 ` Arnaldo Carvalho de Melo
2018-12-13 12:41 ` Arnaldo Carvalho de Melo [this message]
2018-12-13 12:41 ` Arnaldo Carvalho de Melo
2018-12-13 13:09 ` leo.yan
2018-12-13 13:09 ` leo.yan
2018-12-13 13:21 ` Arnaldo Carvalho de Melo
2018-12-13 13:21 ` Arnaldo Carvalho de Melo
2018-12-13 13:23 ` leo.yan
2018-12-13 13:23 ` leo.yan
2018-12-13 13:26 ` Arnaldo Carvalho de Melo
2018-12-13 13:26 ` Arnaldo Carvalho de Melo
2018-12-13 13:31 ` leo.yan
2018-12-13 13:31 ` leo.yan
2018-12-20 18:15 ` [tip:perf/core] " tip-bot for Leo Yan
2018-12-11 7:38 ` [PATCH v3 7/8] perf cs-etm: Treat EO_TRACE " Leo Yan
2018-12-11 7:38 ` Leo Yan
2018-12-20 18:15 ` [tip:perf/core] " tip-bot for Leo Yan
2018-12-11 7:38 ` [PATCH v3 8/8] perf cs-etm: Generate branch sample for exception packet Leo Yan
2018-12-11 7:38 ` Leo Yan
2018-12-20 18:16 ` [tip:perf/core] " tip-bot for Leo Yan
2018-12-12 18:45 ` [PATCH v3 0/8] perf cs-etm: Correct packets handling Mathieu Poirier
2018-12-12 18:45 ` Mathieu Poirier
2018-12-13 13:11 ` Arnaldo Carvalho de Melo
2018-12-13 13:11 ` Arnaldo Carvalho de Melo
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=20181213124154.GF21027@kernel.org \
--to=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=coresight@lists.linaro.org \
--cc=jolsa@redhat.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=namhyung@kernel.org \
--cc=robert.walker@arm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.