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 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.