[PATCH 0/3] tracing: Introduce trace clock tai

[PATCH 0/3] tracing: Introduce trace clock tai

[Kurt Kanzenbach]

Hi,

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.

However, there's no fast accessor for CLOCK_TAI yet. Therefore, patch #1 is
adding one. Patch #2 introduces the clock and the last one adds documentation
for it.

Thanks,
Kurt

Kurt Kanzenbach (3):
  timekeeping: Introduce fast accessor to clock tai
  tracing: Introduce trace clock tai
  tracing: Add documentation for trace clock tai

 Documentation/trace/ftrace.rst | 12 ++++++++++++
 include/linux/timekeeping.h    |  1 +
 kernel/time/timekeeping.c      | 17 +++++++++++++++++
 kernel/trace/trace.c           |  1 +
 4 files changed, 31 insertions(+)

-- 
2.30.2

[PATCH 1/3] timekeeping: Introduce fast accessor to clock tai

[Kurt Kanzenbach]

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>
---
 include/linux/timekeeping.h |  1 +
 kernel/time/timekeeping.c   | 17 +++++++++++++++++
 2 files changed, 18 insertions(+)

diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 78a98bdff76d..fe1e467ba046 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -177,6 +177,7 @@ static inline u64 ktime_get_raw_ns(void)
 extern u64 ktime_get_mono_fast_ns(void);
 extern u64 ktime_get_raw_fast_ns(void);
 extern u64 ktime_get_boot_fast_ns(void);
+extern u64 ktime_get_tai_fast_ns(void);
 extern u64 ktime_get_real_fast_ns(void);
 
 /*
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index dcdcb85121e4..fd639a7e532e 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -532,6 +532,23 @@ u64 notrace ktime_get_boot_fast_ns(void)
 }
 EXPORT_SYMBOL_GPL(ktime_get_boot_fast_ns);
 
+/**
+ * ktime_get_tai_fast_ns - NMI safe and fast access to tai clock.
+ *
+ * The same limitations as described for ktime_get_boot_fast_ns() apply: The
+ * mono time and the TAI offset are not read atomically which may yield wrong
+ * readouts. However, an update of the TAI offset is an rare event e.g., caused
+ * by settime or adjtimex with an offset. The user of this function has to deal
+ * with the possibility of wrong timestamps in post processing.
+ */
+u64 notrace ktime_get_tai_fast_ns(void)
+{
+	struct timekeeper *tk = &tk_core.timekeeper;
+
+	return (ktime_get_mono_fast_ns() + ktime_to_ns(tk->offs_tai));
+}
+EXPORT_SYMBOL_GPL(ktime_get_tai_fast_ns);
+
 static __always_inline u64 __ktime_get_real_fast(struct tk_fast *tkf, u64 *mono)
 {
 	struct tk_read_base *tkr;
-- 
2.30.2

[PATCH 2/3] tracing: Introduce trace clock tai

[Kurt Kanzenbach]

A fast/NMI safe accessor for CLOCK_TAI has been introduced.
Use it for adding the additional trace clock "tai".

Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
---
 kernel/trace/trace.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index f4de111fa18f..7be87b29c6c1 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -1542,6 +1542,7 @@ static struct {
 	{ ktime_get_mono_fast_ns,	"mono",		1 },
 	{ ktime_get_raw_fast_ns,	"mono_raw",	1 },
 	{ ktime_get_boot_fast_ns,	"boot",		1 },
+	{ ktime_get_tai_fast_ns,	"tai",		1 },
 	ARCH_TRACE_CLOCKS
 };
 
-- 
2.30.2

[PATCH 3/3] tracing: Add documentation for trace clock tai

[Kurt Kanzenbach]

Add documentation for new introduced trace clock tai.
This clock corresponds to CLOCK_TAI.

Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
---
 Documentation/trace/ftrace.rst | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
index 45b8c56af67a..b37dc19e4d40 100644
--- a/Documentation/trace/ftrace.rst
+++ b/Documentation/trace/ftrace.rst
@@ -517,6 +517,18 @@ of ftrace. Here is a list of some of the key files:
 		processing should be able to handle them. See comments in the
 		ktime_get_boot_fast_ns() function for more information.
 
+	tai:
+		This is the tai clock (CLOCK_TAI) and is derived from the wall-
+		clock time. However, this clock does not experience
+		discontinuities and backwards jumps caused by NTP inserting leap
+		seconds. Since the clock access is designed for use in tracing,
+		side effects are possible. The clock access may yield wrong
+		readouts in case the internal TAI offset is updated e.g., caused
+		by setting the system time or using adjtimex() with an offset.
+		These effects are rare and post processing should be able to
+		handle them. See comments in the ktime_get_tai_fast_ns()
+		function for more information.
+
 	To set a clock, simply echo the clock name into this file::
 
 	  # echo global > trace_clock
-- 
2.30.2

Re: [PATCH 1/3] timekeeping: Introduce fast accessor to clock tai

[Steven Rostedt]

On Sat,  9 Apr 2022 10:12:58 +0200
Kurt Kanzenbach <kurt@linutronix.de> wrote:

> ---
>  include/linux/timekeeping.h |  1 +
>  kernel/time/timekeeping.c   | 17 +++++++++++++++++
>  2 files changed, 18 insertions(+)

If the time keeping folks are OK with this and ack it, I'm happy to
take this through my tree.

-- Steve

Re: [PATCH 1/3] timekeeping: Introduce fast accessor to clock tai

[Thomas Gleixner]

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>

Re: [PATCH 1/3] timekeeping: Introduce fast accessor to clock tai

[Thomas Gleixner]

On Sat, Apr 09 2022 at 09:37, Steven Rostedt wrote:
> On Sat,  9 Apr 2022 10:12:58 +0200
> Kurt Kanzenbach <kurt@linutronix.de> wrote:
>
>> ---
>>  include/linux/timekeeping.h |  1 +
>>  kernel/time/timekeeping.c   | 17 +++++++++++++++++
>>  2 files changed, 18 insertions(+)
>
> If the time keeping folks are OK with this and ack it, I'm happy to
> take this through my tree.

Go ahead. I just sent a Reviewed-by and I don't see conflicting changes
in that area. Famous last words :)

Thanks,

        tglx

Re: [PATCH 1/3] timekeeping: Introduce fast accessor to clock tai

[Thomas Gleixner]

On Sat, Apr 09 2022 at 22:33, Thomas Gleixner wrote:
> On Sat, Apr 09 2022 at 09:37, Steven Rostedt wrote:
>> On Sat,  9 Apr 2022 10:12:58 +0200
>> Kurt Kanzenbach <kurt@linutronix.de> wrote:
>>
>>> ---
>>>  include/linux/timekeeping.h |  1 +
>>>  kernel/time/timekeeping.c   | 17 +++++++++++++++++
>>>  2 files changed, 18 insertions(+)
>>
>> If the time keeping folks are OK with this and ack it, I'm happy to
>> take this through my tree.
>
> Go ahead. I just sent a Reviewed-by and I don't see conflicting changes
> in that area. Famous last words :)

And yes, I have some conflicting changes in the pipeline and just saw
that this lacks a data_race() annotation like the boot variant from
which this is derived.

Let me pick this up into a rc2 based branch. I'll tag it and provide it
to you for consumption.

Thanks,

        tglx

Re: [PATCH 1/3] timekeeping: Introduce fast accessor to clock tai

[Kurt Kanzenbach]

[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]

On Mon Apr 11 2022, Thomas Gleixner wrote:
> On Sat, Apr 09 2022 at 22:33, Thomas Gleixner wrote:
>> On Sat, Apr 09 2022 at 09:37, Steven Rostedt wrote:
>>> On Sat,  9 Apr 2022 10:12:58 +0200
>>> Kurt Kanzenbach <kurt@linutronix.de> wrote:
>>>
>>>> ---
>>>>  include/linux/timekeeping.h |  1 +
>>>>  kernel/time/timekeeping.c   | 17 +++++++++++++++++
>>>>  2 files changed, 18 insertions(+)
>>>
>>> If the time keeping folks are OK with this and ack it, I'm happy to
>>> take this through my tree.
>>
>> Go ahead. I just sent a Reviewed-by and I don't see conflicting changes
>> in that area. Famous last words :)
>
> And yes, I have some conflicting changes in the pipeline and just saw
> that this lacks a data_race() annotation like the boot variant from
> which this is derived.

Interesting, didn't see that annotation. Anyway, this patch also misses
the corresponding documentation entry. See below.

Thanks,
Kurt

diff --git a/Documentation/core-api/timekeeping.rst b/Documentation/core-api/timekeeping.rst
index 729e24864fe7..22ec68f24421 100644
--- a/Documentation/core-api/timekeeping.rst
+++ b/Documentation/core-api/timekeeping.rst
@@ -132,6 +132,7 @@ Some additional variants exist for more specialized cases:
 .. c:function:: u64 ktime_get_mono_fast_ns( void )
                u64 ktime_get_raw_fast_ns( void )
                u64 ktime_get_boot_fast_ns( void )
+               u64 ktime_get_tai_fast_ns( void )
                u64 ktime_get_real_fast_ns( void )

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]