[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210628072905.GB200044@leoy-ThinkPad-X240s>
Date: Mon, 28 Jun 2021 15:29:05 +0800
From: Leo Yan <leo.yan@...aro.org>
To: Yang Jihong <yangjihong1@...wei.com>
Cc: john.garry@...wei.com, will@...nel.org, mathieu.poirier@...aro.org,
peterz@...radead.org, mingo@...hat.com, acme@...nel.org,
mark.rutland@....com, alexander.shishkin@...ux.intel.com,
jolsa@...hat.com, namhyung@...nel.org, james.clark@....com,
andre.przywara@....com, linux-arm-kernel@...ts.infradead.org,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] perf arm-spe: Fix incorrect sample timestamp in perf
script
On Mon, Jun 28, 2021 at 02:30:56PM +0800, Yang Jihong wrote:
> Hello Leo,
>
> On 2021/6/28 12:07, Leo Yan wrote:
> > On Mon, Jun 28, 2021 at 11:45:07AM +0800, Yang Jihong wrote:
> >
> > [...]
> >
> > > The timestamp does not match. Each timestamp has a difference of
> > > 213.98296702 seconds. Is the command I executed wrong?
> >
> > I don't understand what's your meaning "a difference of 213.98296702
> > seconds".
> >
> > But let me give an explaination with your below examples. You could
> > the command "perf script" outputs the timestamp 314938.859071370 which
> > is the kernel's timestamp, if using the command "perf script -D", it
> > outputs the value 31515284203839 which is the Arch timer's raw counter
> > value.
> >
> > In theory, the arch timer's counter is enabled at the very early
> > time before kernel's booting (e.g. bootloaders, UEFI, etc...). So for
> > the kernel's timestamp, it should calibrate the timestamp and reduce
> > the offset prior to the kernel's booting. I think this is the reason
> > why you observed 213.98296702 seconds difference (if compared with
> > your own patch?)
> >
> > If still see any issue, please let me know. Thanks a lot for the
> > testing!
> >
> Thanks for the very detailed explanation.
> To keep the correct relative time sequence between events in SPE and other
> events, we should use kernel timestamp instead of arch time. Therefore, we
> need to calibrate the time. Is this correct?
Yes, correct!
Powered by blists - more mailing lists