From: Richard Cochran <richardcochran@gmail.com>
To: "Christopher S. Hall" <christopher.s.hall@intel.com>
Cc: jeffrey.t.kirsher@intel.com, hpa@zytor.com, mingo@redhat.com,
tglx@linutronix.de, john.stultz@linaro.org, peterz@infradead.org,
x86@kernel.org, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kevin.b.stanton@intel.com
Subject: Re: [PATCH v4 1/4] Produce system time from correlated clocksource
Date: Tue, 13 Oct 2015 15:50:32 +0200 [thread overview]
Message-ID: <20151013135032.GA5422@localhost.localdomain> (raw)
In-Reply-To: <1444675522-4198-2-git-send-email-christopher.s.hall@intel.com>
Now that I am starting to understand what this code is trying to
achieve...
On Mon, Oct 12, 2015 at 11:45:19AM -0700, Christopher S. Hall wrote:
> The modification to the original patch accomodates these
> slow devices by adding the option of providing an ART value outside
> of the retry loop and adding a history which can consulted in the
> case of an out of date counter value. The history is kept by
> making the shadow_timekeeper an array. Each write to the
> timekeeper rotates through the array, preserving a
> history of updates.
You did not provide an example of how this function is called, in the
special case where correlated_ts.get_ts = NULL and the caller provides
system_ts and device_ts. Until that user appears, we do not need the
interface at all.
> +/* This needs to be 3 or greater for backtracking to be useful */
> +#define SHADOW_HISTORY_DEPTH 7
Why then have you put 7?
This comment should really explain what is needed and why.
> +/**
> + * get_correlated_timestamp - Get a correlated timestamp
This function is tremendously confusing. The overloading with special
semenatics when the callback is NULL is not nice. There is hardly
much shared logic, and so nothing speaks against having two methods.
I would call them "get_correlated_timestamp" and "correlate_timestamp"
or similar. The "get_" prefix in the name is totally misleading in
your special case.
> + * @crs: conversion between correlated clock and system clock
> + * @crt: callback to get simultaneous device and correlated clock value *or*
> + * contains a valid correlated clock value and NULL callback
This description stinks. What is crs? It is *not* a conversion. It is:
struct correlated_ts - Descriptor for taking a correlated time stamp
What is crt? It is *not* a callback. It is:
struct correlated_cs - Descriptor for a clocksource correlated to another
For the crt, the kerneldoc should explain which of the fields
int (*get_ts)(struct correlated_ts *ts);
u64 system_ts;
u64 device_ts;
ktime_t system_real;
ktime_t system_raw;
void *private;
are provided by the caller and which are set by the function. The
fact that fields are set either by the caller or by the method is a
funny code smell.
> + *
> + * Reads a timestamp from a device and correlates it to system time. This
> + * function can be used in two ways. If a non-NULL get_ts function pointer is
> + * supplied in @crt, this function is called within the retry loop to
> + * read the current correlated clock value and associated device time.
> + * Otherwise (get_ts is NULL) a correlated clock value is supplied and
> + * the history in shadow_timekeeper is consulted if necessary.
> + */
> +int get_correlated_timestamp(struct correlated_ts *crt,
> + struct correlated_cs *crs)
> +{
...
> + do {
This code is only used in the special case:
> + /*
> + * Since the cycles value is supplied outside of the loop,
> + * there is no guarantee that it represents a time *after*
> + * cycle_last do some checks to figure out whether it's
> + * represents the past or the future taking rollover
> + * into account. If the value is in the past, try to backtrack
> + */
BTW, isn't there an easier way to deal with time stamps in the past?
(Compare with timecounter_cyc2time.)
> + cycles_now = tk->tkr_mono.read(tk->tkr_mono.clock);
> + cycles_last = tk->tkr_mono.cycle_last;
> + if ((cycles >= cycles_last && cycles_now < cycles) ||
> + (cycles < cycles_last && cycles_now >= cycles_last)) {
> + /* cycles is in the past try to backtrack */
> + int backtrack_index = shadow_index;
> +
> + while (get_prev_shadow_index(&backtrack_index)) {
> + tk = shadow_timekeeper+backtrack_index;
> + if (cycle_between(cycles_last, cycles,
> + tk->tkr_mono.cycle_last))
> + goto do_convert;
> + cycles_last = tk->tkr_mono.cycle_last;
> + }
> + return -EAGAIN;
> + }
And this is the shared stuff:
> +do_convert:
> + /* Convert to clock realtime */
> + base = ktime_add(tk->tkr_mono.base,
> + tk_core.timekeeper.offs_real);
> + nsecs = timekeeping_convert_to_ns(&tk->tkr_mono, cycles);
> + crt->system_real = ktime_add_ns(base, nsecs);
> +
> + /* Convert to clock raw monotonic */
> + base = tk->tkr_raw.base;
> + nsecs = timekeeping_convert_to_ns(&tk->tkr_raw, cycles);
> + crt->system_raw = ktime_add_ns(base, nsecs);
> +
> + } while (read_seqcount_retry(&tk_core.seq, seq));
> + return 0;
> +}
I suggest moving the shared stuff into a subroutine and providing two
different functions.
Thanks,
Richard
next prev parent reply other threads:[~2015-10-13 13:50 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-12 18:45 [PATCH v4 0/4] Patchset enabling hardware based cross-timestamps for next gen Intel platforms Christopher S. Hall
2015-10-12 18:45 ` [PATCH v4 1/4] Produce system time from correlated clocksource Christopher S. Hall
2015-10-13 4:58 ` Richard Cochran
2015-10-13 7:51 ` Thomas Gleixner
2015-10-13 8:31 ` Richard Cochran
2015-10-13 19:15 ` Thomas Gleixner
2015-10-13 21:12 ` Richard Cochran
2015-10-14 7:21 ` Thomas Gleixner
2015-10-14 9:29 ` Richard Cochran
2015-10-14 14:22 ` Thomas Gleixner
2015-10-14 16:18 ` Richard Cochran
2015-10-15 2:34 ` Christopher Hall
2015-10-15 5:41 ` Richard Cochran
2015-10-15 8:13 ` Thomas Gleixner
2015-10-13 5:26 ` Richard Cochran
2015-10-13 13:50 ` Richard Cochran [this message]
2015-10-13 19:42 ` Thomas Gleixner
2015-10-15 1:57 ` Christopher Hall
2015-10-15 5:57 ` Richard Cochran
2015-10-15 8:15 ` Thomas Gleixner
2015-10-20 0:18 ` Christopher Hall
2015-10-20 0:36 ` John Stultz
2015-10-20 8:54 ` Richard Cochran
2015-10-20 10:48 ` Thomas Gleixner
2015-10-20 11:51 ` Richard Cochran
2015-10-20 14:55 ` Richard Cochran
2015-10-20 19:11 ` Thomas Gleixner
2015-10-20 19:36 ` Richard Cochran
2015-10-20 20:16 ` John Stultz
2015-10-21 7:44 ` Thomas Gleixner
2015-11-03 19:18 ` Stanton, Kevin B
2015-11-09 21:17 ` John Stultz
2015-10-12 18:45 ` [PATCH v4 2/4] Always running timer " Christopher S. Hall
2015-10-13 2:03 ` kbuild test robot
2015-11-18 23:53 ` Jacob Pan
2015-10-12 18:45 ` [PATCH v4 3/4] Add PTP_SYS_OFFSET_PRECISE for driver crosstimestamping Christopher S. Hall
2015-10-13 13:59 ` Richard Cochran
2015-10-15 2:47 ` Christopher Hall
2015-11-07 2:15 ` Christopher Hall
2015-10-12 18:45 ` [PATCH v4 4/4] Adds hardware supported cross timestamp Christopher S. Hall
2015-10-13 2:10 ` kbuild test robot
2015-10-13 2:11 ` kbuild test robot
2015-10-13 2:31 ` David Miller
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=20151013135032.GA5422@localhost.localdomain \
--to=richardcochran@gmail.com \
--cc=christopher.s.hall@intel.com \
--cc=hpa@zytor.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jeffrey.t.kirsher@intel.com \
--cc=john.stultz@linaro.org \
--cc=kevin.b.stanton@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@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).