From: Leo Yan <leo.yan@linaro.org>
To: James Clark <james.clark@arm.com>
Cc: coresight@lists.linaro.org, mathieu.poirier@linaro.org,
al.grant@arm.com, branislav.rankov@arm.com, denik@chromium.org,
suzuki.poulose@arm.com, anshuman.khandual@arm.com,
Mike Leach <mike.leach@linaro.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
John Garry <john.garry@huawei.com>, Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] perf cs-etm: Handle valid-but-zero timestamps
Date: Tue, 11 May 2021 16:05:04 +0800 [thread overview]
Message-ID: <20210511080504.GC8273@leoy-ThinkPad-X240s> (raw)
In-Reply-To: <20210510053904.GB4835@leoy-ThinkPad-X240s>
On Mon, May 10, 2021 at 01:39:04PM +0800, Leo Yan wrote:
> On Fri, May 07, 2021 at 01:02:35PM +0300, James Clark wrote:
> >
> >
> > On 07/05/2021 12:58, James Clark wrote:
> > > There is an intermittent issue on Trogdor devices that
> > > results in all Coresight timestamps having a value of zero.
> >
> > I've attached a file here that has the issue. From the dump you
> > can see the zero timestamps:
> >
> > Idx:69; ID:10; I_TIMESTAMP : Timestamp.; Updated val = 0x0
> > Idx:71; ID:10; I_ATOM_F1 : Atom format 1.; E
> > Idx:72; ID:10; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xFFFFFFE723C65824 ~[0x5824]
> >
> > This doesn't have an impact on decoding as they end up being
> > decoded in file order as in with timeless mode.
>
> Just remind, as Mike has mentioned that if the timestamp is zero, it
> means the hardware setting for timestamp is not enabled properly. So
> for system wide or per CPU mode tracing, it's better to double check
> what's the reason the timestamp is not enabled properly.
>
> IIUC, this patch breaks the existed rational in the code. Let's think
> about there have 4 CPUs, every CPU has its own AUX trace buffer, and
> when decode the trace data, it will use 4 queues to track the packets
> and every queue has its timestamp.
>
> CPU0: cs_etm_queue -> ... -> packet_queue->timestamp
> CPU1: cs_etm_queue -> ... -> packet_queue->timestamp
> CPU2: cs_etm_queue -> ... -> packet_queue->timestamp
> CPU3: cs_etm_queue -> ... -> packet_queue->timestamp
>
> The issue is if all CPUs' timestamp are zero, it's impossible to find
> a way to synthesize samples in the right time order.
I saw Denis's replying for the hardware issue for timestamp, wander if
can add a new option "--force-aux-ts-zero" to override the hardware
timestamp issue. Without the option "--force-aux-ts-zero", the
developers still have chance to observe the failure case caused by the
abnormal timestamps.
Thanks,
Leo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-05-11 12:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-07 9:58 [RFC PATCH] perf cs-etm: Handle valid-but-zero timestamps James Clark
[not found] ` <3926c523-3fdb-66de-8b9c-b68290a5053e@arm.com>
2021-05-07 14:09 ` Mike Leach
2021-05-11 7:39 ` Denis Nikitin
2021-05-11 10:07 ` James Clark
2021-05-10 5:39 ` Leo Yan
2021-05-11 8:05 ` Leo Yan [this message]
2021-05-11 10:00 ` James Clark
2021-05-11 8:06 ` Denis Nikitin
2021-05-11 8:26 ` Leo Yan
2021-05-11 13:53 ` James Clark
2021-05-12 1:20 ` Leo Yan
2021-05-13 13:57 ` James Clark
2021-05-12 2:08 ` Leo Yan
2021-05-13 13:10 ` James Clark
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=20210511080504.GC8273@leoy-ThinkPad-X240s \
--to=leo.yan@linaro.org \
--cc=al.grant@arm.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=anshuman.khandual@arm.com \
--cc=branislav.rankov@arm.com \
--cc=coresight@lists.linaro.org \
--cc=denik@chromium.org \
--cc=james.clark@arm.com \
--cc=john.garry@huawei.com \
--cc=jolsa@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.poirier@linaro.org \
--cc=mike.leach@linaro.org \
--cc=namhyung@kernel.org \
--cc=suzuki.poulose@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).