All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: Richard Cochran <richardcochran@gmail.com>,
	netdev@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>, "H . Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	"Christopher S . Hall" <christopher.s.hall@intel.com>
Subject: Re: [RFC PATCH 1/5] x86: tsc: add tsc to art helpers
Date: Thu, 15 Aug 2019 16:16:09 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.21.1908151458560.1923@nanos.tec.linutronix.de> (raw)
In-Reply-To: <87y2zvt1hk.fsf@gmail.com>

Felipe,

On Thu, 15 Aug 2019, Felipe Balbi wrote:
> Thomas Gleixner <tglx@linutronix.de> writes:
> > On Tue, 16 Jul 2019, Felipe Balbi wrote:
> >
> > So some information what those interfaces are used for and why they are
> > needed would be really helpful.
> 
> Okay, I have some more details about this. The TGPIO device itself uses
> ART since TSC is not directly available to anything other than the
> CPU. The 'problem' here is that reading ART incurs extra latency which
> we would like to avoid. Therefore, we use TSC and scale it to
> nanoseconds which, would be the same as ART to ns.

Fine. But that's not really correct:

      TSC = art_to_tsc_offset + ART * scale;
 
> >> +void get_tsc_ns(struct system_counterval_t *tsc_counterval, u64 *tsc_ns)

Why is this not returning the result instead of having that pointer
indirection?

> >> +{
> >> +	u64 tmp, res, rem;
> >> +	u64 cycles;
> >> +
> >> +	tsc_counterval->cycles = clocksource_tsc.read(NULL);
> >> +	cycles = tsc_counterval->cycles;
> >> +	tsc_counterval->cs = art_related_clocksource;

So this does more than returning the TSC time converted to nanoseconds. The
function name should reflect this. Plus both functions want kernel-doc
explaining what they do.

> >> +	rem = do_div(cycles, tsc_khz);
> >> +
> >> +	res = cycles * USEC_PER_SEC;
> >> +	tmp = rem * USEC_PER_SEC;
> >> +
> >> +	do_div(tmp, tsc_khz);
> >> +	res += tmp;
> >> +
> >> +	*tsc_ns = res;
> >> +}
> >> +EXPORT_SYMBOL(get_tsc_ns);
> >> +
> >> +u64 get_art_ns_now(void)
> >> +{
> >> +	struct system_counterval_t tsc_cycles;
> >> +	u64 tsc_ns;
> >> +
> >> +	get_tsc_ns(&tsc_cycles, &tsc_ns);
> >> +
> >> +	return tsc_ns;
> >> +}
> >> +EXPORT_SYMBOL(get_art_ns_now);
> >
> > While the changes look innocuous I'm missing the big picture why this needs
> > to emulate ART instead of simply using TSC directly.
> 
> i don't think we're emulating ART here (other than the name in the
> function). We're just reading TSC and converting to nanoseconds, right?

Well, the function name says clearly: get_art_ns_now(). But you are not
using ART, you use the TSC and derive the ART value from it (incorrectly).

Thanks,

	tglx


  reply	other threads:[~2019-08-15 14:16 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-16  7:20 [RFC PATCH 0/5] PTP: add support for Intel's TGPIO controller Felipe Balbi
2019-07-16  7:20 ` [RFC PATCH 1/5] x86: tsc: add tsc to art helpers Felipe Balbi
2019-07-16  7:57   ` Thomas Gleixner
2019-08-15  5:57     ` Felipe Balbi
2019-08-15 14:16       ` Thomas Gleixner [this message]
2019-10-01 10:24         ` Felipe Balbi
2019-10-17 11:15           ` Thomas Gleixner
2019-10-17 12:01             ` Felipe Balbi
2019-07-16  7:20 ` [RFC PATCH 2/5] PTP: add a callback for counting timestamp events Felipe Balbi
2019-07-16  7:20 ` [RFC PATCH 3/5] PTP: implement PTP_EVENT_COUNT_TSTAMP ioctl Felipe Balbi
2019-07-16  7:20 ` [RFC PATCH 4/5] PTP: Add flag for non-periodic output Felipe Balbi
2019-07-16 16:39   ` Richard Cochran
2019-07-17  6:49     ` Felipe Balbi
2019-07-17 17:36       ` Richard Cochran
2019-07-18  8:59         ` Felipe Balbi
2019-07-18 16:41           ` Richard Cochran
2019-08-13  7:53             ` Felipe Balbi
2019-08-13 17:48               ` Richard Cochran
2019-08-13 18:06                 ` Richard Cochran
2019-08-14  7:05                   ` Felipe Balbi
2019-07-16  7:20 ` [RFC PATCH 5/5] PTP: Add support for Intel PMC Timed GPIO Controller Felipe Balbi
2019-07-16 19:14   ` Shannon Nelson
2019-07-17  6:51     ` Felipe Balbi
2019-07-16 16:41 ` [RFC PATCH 0/5] PTP: add support for Intel's TGPIO controller Richard Cochran
2019-07-17  6:52   ` Felipe Balbi
2019-07-17 17:39     ` Richard Cochran
2019-07-18  8:58       ` Felipe Balbi
2019-07-18 19:50 ` Andrew Lunn
2019-07-19  7:35   ` Felipe Balbi
2019-07-19 13:20     ` Andrew Lunn
2019-08-13  7:50       ` Felipe Balbi
2019-08-13 17:49         ` Richard Cochran

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.1908151458560.1923@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=bp@alien8.de \
    --cc=christopher.s.hall@intel.com \
    --cc=felipe.balbi@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    --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 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.