From: David Ahern <dsahern@gmail.com>
To: peterz@infradead.org, Andi Kleen <ak@linux.intel.com>
Cc: "Jiri Olsa" <jolsa@redhat.com>, "Jiri Olsa" <jolsa@kernel.org>,
"Arnaldo Carvalho de Melo" <acme@kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
"Ingo Molnar" <mingo@kernel.org>,
"Namhyung Kim" <namhyung@kernel.org>,
"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
"Michael Petlan" <mpetlan@redhat.com>,
"Ian Rogers" <irogers@google.com>,
"Geneviève Bastien" <gbastien@versatic.net>,
"Wang Nan" <wangnan0@huawei.com>,
"Jeremie Galarneau" <jgalar@efficios.com>
Subject: Re: [PATCH 0/6] perf tools: Add wallclock time conversion support
Date: Fri, 31 Jul 2020 18:46:21 -0600 [thread overview]
Message-ID: <27a4663d-bc71-5f52-5871-23d4061fe575@gmail.com> (raw)
In-Reply-To: <20200731180539.GA2674@hirez.programming.kicks-ass.net>
On 7/31/20 12:05 PM, peterz@infradead.org wrote:
> On Fri, Jul 31, 2020 at 08:36:12AM -0700, Andi Kleen wrote:
>>> yep, we have a customer that needs to compare data from multiple servers
>>
>> It's also needed to correlate over different guests on the same machine.
>> This is an important use case.
>
> Both these cases you want to sync up CLOCK_MONOTONIC, using walltime is
> just utterly misguided.
Every userspace component logs in walltime. You can say that is
misguided, but that is the way it is. The missing piece is the ability
to correlate kernel events to userspace logs.
>
> What happens if the servers have (per accident or otherwise) different
> DST settings, or someone does a clock_setttime() for giggles.
Yes, someone *could* change the time. Someone *could* start ntpd or
other time server in the middle of a session. While technically such
things can happen, that is not real life in most environments (e.g.,
Data center servers). ntpd (or other) is started at boot, and it is just
the little misc adjustments that happen over time.
We could add tracepoints and detect the changes and invalidate the
reference time. We could add tracepoints to track the adjustments and
update the reference time. In my experience over 9+ years using this
tool (out of tree patches) that has never been the problem.
>
> All you really want is a clock that runs at the same rate but is not
> subject to random jumps and user foibles.
>
All I want is to compare user logs to a kernel event via timestamps.
next prev parent reply other threads:[~2020-08-01 0:46 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-30 21:39 [PATCH 0/6] perf tools: Add wallclock time conversion support Jiri Olsa
2020-07-30 21:39 ` [PATCH 1/6] perf tools: Add clockid_name function Jiri Olsa
2020-07-31 15:33 ` Andi Kleen
2020-07-31 16:19 ` Jiri Olsa
2020-07-30 21:39 ` [PATCH 2/6] perf tools: Store clock references for -k/--clockid option Jiri Olsa
2020-07-31 15:52 ` Alexey Budankov
2020-07-31 16:15 ` Jiri Olsa
2020-07-31 16:35 ` David Ahern
2020-08-03 3:55 ` Namhyung Kim
2020-08-03 11:35 ` Jiri Olsa
2020-07-30 21:39 ` [PATCH 3/6] perf tools: Move clockid_res_ns under clock struct Jiri Olsa
2020-07-30 21:39 ` [PATCH 4/6] perf tools: Add support to store time of day in CTF data conversion Jiri Olsa
2020-08-03 4:00 ` Namhyung Kim
2020-08-03 11:31 ` Jiri Olsa
2020-07-30 21:39 ` [PATCH 5/6] perf script: Change enum perf_output_field values to be 64 bits Jiri Olsa
2020-07-30 21:39 ` [PATCH 6/6] perf script: Add tod field to display time of day Jiri Olsa
2020-07-30 22:14 ` [PATCH 0/6] perf tools: Add wallclock time conversion support peterz
2020-07-31 1:21 ` David Ahern
2020-07-31 7:47 ` Jiri Olsa
2020-07-31 15:36 ` Andi Kleen
2020-07-31 18:05 ` peterz
2020-08-01 0:46 ` David Ahern [this message]
2020-08-01 17:49 ` Arnaldo Carvalho de Melo
2020-07-31 17:20 ` peterz
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=27a4663d-bc71-5f52-5871-23d4061fe575@gmail.com \
--to=dsahern@gmail.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=gbastien@versatic.net \
--cc=irogers@google.com \
--cc=jgalar@efficios.com \
--cc=jolsa@kernel.org \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mpetlan@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=wangnan0@huawei.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 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).