From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: David Ahern <dsahern@gmail.com>
Cc: peterz@infradead.org, "Andi Kleen" <ak@linux.intel.com>,
"Jiri Olsa" <jolsa@redhat.com>, "Jiri Olsa" <jolsa@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: Sat, 1 Aug 2020 14:49:04 -0300 [thread overview]
Message-ID: <20200801174904.GA2740416@kernel.org> (raw)
In-Reply-To: <27a4663d-bc71-5f52-5871-23d4061fe575@gmail.com>
Em Fri, Jul 31, 2020 at 06:46:21PM -0600, David Ahern escreveu:
> 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.
Can we have both possibilities and leave the decision on which one to
use in the hands of those who have a gun to shoot wherever they want,
maybe in the foot?
- Arnaldo
next prev parent reply other threads:[~2020-08-01 17:57 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
2020-08-01 17:49 ` Arnaldo Carvalho de Melo [this message]
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=20200801174904.GA2740416@kernel.org \
--to=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=dsahern@gmail.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