linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: John Stultz <john.stultz@linaro.org>
Cc: Christopher Hall <christopher.s.hall@intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	linux-rt-users <linux-rt-users@vger.kernel.org>,
	jesus.sanchez-palencia@intel.com, gavin.hindman@intel.com,
	liam.r.girdwood@intel.com, Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: TSC to Mono-raw Drift
Date: Fri, 19 Oct 2018 22:50:01 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.21.1810192244150.1651@nanos.tec.linutronix.de> (raw)
In-Reply-To: <CALAqxLVrPH-SFacys6pWBvL79OBwiAMUOL55oy3S7C+7pNffHA@mail.gmail.com>

John,

On Fri, 19 Oct 2018, John Stultz wrote:
> On Fri, Oct 19, 2018 at 11:57 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > I don't think you need complex oscillation for that. The error is constant
> > and small enough that it is a fractional nanoseconds thing with an interval
> > <= 1s. So you can just add that in a regular interval. Due to it being
> > small you can't observe time jumping I think.
> 
> Well, from the examples the trouble is we seem to be a bit fast,
> rather then slow.
> So we'll have to reduce mult by one, and rework the calculations, but
> maybe something like this (correcting the raw_interval value) would
> work.

Shouldn't be rocket science. It's a one off calculation of adjustment value
and maybe the period at which the correction happens.

> But this also sort of breaks, fundamental argument that the raw clock
> is a simple mult/shift transformation of the underlying clocksource
> counter. Its not the accuracy of the clock but the consistency that
> was key.
> 
> The counter argument is that the raw clock is abstracting the
> underlying hardware so folks who would have used the TSC directly can
> now use the raw clock and have a generic abstracted hardware-counter
> interface. So userland shouldn't really be worried about the
> occasional injections made since they shouldn't be trying to
> re-generate the abstraction from the hardware themselves.  <--
> Remember this point as we move to the next comment:)
> 
> > The end-result is 'correct' as much correct it is in relation to real
> > nanoseconds. :)
> >
> >> I guess I'd want to understand more of the use here and the need to
> >> tie the raw clock back to the hardware counter it abstracts.
> >
> > The problem there is ART which is distributed to PCIe devices and ART time
> > stamps are exposed in various ways. ART has a fixed ratio vs. TSC so there
> > is a reasonable expectation that MONOTONIC_RAW is accurate.
> 
> Which is maybe sort of my issue here. The raw clock provided a
> abstraction away from the hardware for generic usage, but then its
> being re-used with other un-abstracted hardware references. So unless
> they use the same method of transformation, there will be problems (of
> varying degree).

OTOH. If people use the CPUID provided frequency information and the TSC
from userspace then they get different results which is contrary to the
goal of providing them an abstracted way of doing it.

> We might be able to reduce the degree in this case, but I worry the
> extra complexity may only cause problems for others.

Is it really that complex to add a fixed correction value periodically?

I don't think so and it should just work for any clocksource which is
exposed this way. Famous last words .....

Thanks,

	tglx

  reply	other threads:[~2018-10-19 20:50 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20181015160945.5993-1-christopher.s.hall@intel.com>
2018-10-19 15:25 ` Thomas Gleixner
2018-10-19 18:34   ` John Stultz
2018-10-19 18:39     ` John Stultz
2018-10-19 18:37   ` Thomas Gleixner
2018-10-19 18:48     ` John Stultz
2018-10-19 18:57       ` Thomas Gleixner
2018-10-19 19:21         ` John Stultz
2018-10-19 20:50           ` Thomas Gleixner [this message]
2018-10-19 22:36             ` John Stultz
2018-10-23 18:31               ` John Stultz
2018-10-24 14:51                 ` Miroslav Lichvar
2018-10-24 17:32                   ` Christopher Hall
2018-10-25 11:49                     ` Miroslav Lichvar
2018-11-01 17:41                   ` Thomas Gleixner
2018-11-02 10:26                     ` Miroslav Lichvar
2018-11-02 11:27                       ` Thomas Gleixner
2018-11-01 17:44                 ` Thomas Gleixner
2018-11-01 17:56                   ` John Stultz
2018-11-01 18:03                     ` Thomas Gleixner
2018-11-02 11:20                       ` Miroslav Lichvar
2018-11-02 11:25                         ` Thomas Gleixner
2018-11-02 12:31                           ` Miroslav Lichvar

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=alpine.DEB.2.21.1810192244150.1651@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=christopher.s.hall@intel.com \
    --cc=gavin.hindman@intel.com \
    --cc=hpa@zytor.com \
    --cc=jesus.sanchez-palencia@intel.com \
    --cc=john.stultz@linaro.org \
    --cc=liam.r.girdwood@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=peterz@infradead.org \
    --subject='Re: TSC to Mono-raw Drift' \
    /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

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