All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Kurt Kanzenbach <kurt@linutronix.de>,
	John Stultz <john.stultz@linaro.org>,
	Stephen Boyd <sboyd@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@redhat.com>, Jonathan Corbet <corbet@lwn.net>
Cc: Richard Cochran <richardcochran@gmail.com>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	Kurt Kanzenbach <kurt@linutronix.de>
Subject: Re: [PATCH 1/3] timekeeping: Introduce fast accessor to clock tai
Date: Sat, 09 Apr 2022 22:32:21 +0200	[thread overview]
Message-ID: <874k32huay.ffs@tglx> (raw)
In-Reply-To: <20220409081300.4762-2-kurt@linutronix.de>

On Sat, Apr 09 2022 at 10:12, Kurt Kanzenbach wrote:
> Introduce fast/NMI safe accessor to clock tai for tracing. The Linux kernel
> tracing infrastructure has support for using different clocks to generate
> timestamps for trace events. Especially in TSN networks it's useful to have TAI
> as trace clock, because the application scheduling is done in accordance to the
> network time, which is based on TAI. With a tai trace_clock in place, it becomes
> very convenient to correlate network activity with Linux kernel application
> traces.
>
> Use the same implementation as ktime_get_boot_fast_ns() does by reading the
> monotonic time and adding the TAI offset. The same limitations as for the fast
> boot implementation apply. The TAI offset may change at run time e.g., by
> setting the time or using adjtimex() with an offset. However, these kind of
> offset changes are rare events. Nevertheless, the user has to be aware and deal
> with it in post processing.
>
> An alternative approach would be to use the same implementation as
> ktime_get_real_fast_ns() does. However, this requires to add an additional u64
> member to the tk_read_base struct. This struct together with a seqcount is
> designed to fit into a single cache line on 64 bit architectures. Adding a new
> member would violate this constraint.
>
> Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>

Nice changelog!

Reviewed-by: Thomas Gleixner <tglx@linutronix.de>

  parent reply	other threads:[~2022-04-09 20:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-09  8:12 [PATCH 0/3] tracing: Introduce trace clock tai Kurt Kanzenbach
2022-04-09  8:12 ` [PATCH 1/3] timekeeping: Introduce fast accessor to " Kurt Kanzenbach
2022-04-09 13:37   ` Steven Rostedt
2022-04-09 20:33     ` Thomas Gleixner
2022-04-11 20:58       ` Thomas Gleixner
2022-04-12  7:03         ` Kurt Kanzenbach
2022-04-09 20:32   ` Thomas Gleixner [this message]
2022-04-09  8:12 ` [PATCH 2/3] tracing: Introduce trace " Kurt Kanzenbach
2022-04-09  8:13 ` [PATCH 3/3] tracing: Add documentation for " Kurt Kanzenbach

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=874k32huay.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=corbet@lwn.net \
    --cc=john.stultz@linaro.org \
    --cc=kurt@linutronix.de \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=richardcochran@gmail.com \
    --cc=rostedt@goodmis.org \
    --cc=sboyd@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.