netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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