Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp142697pxb; Thu, 14 Apr 2022 18:15:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJztzPl/TxZWzWyUlJaGWa7X6CvzvtWJPTN6Yj9e+Oi1kmGMYv3ay2N4N3BAuaauBkTdGzsa X-Received: by 2002:a05:6a00:1a55:b0:4fd:ef0c:fad1 with SMTP id h21-20020a056a001a5500b004fdef0cfad1mr6518777pfv.50.1649985323224; Thu, 14 Apr 2022 18:15:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649985323; cv=none; d=google.com; s=arc-20160816; b=KuNWjeDRONF3dfxDd4cXIzuoskgz0gDe3Ax7L+hHUMT5azW7iW8MMOcfLSPa2JaTgf a1m6LGkCiRCDhU3FS1P7Y3fo/DWZbhmYjv05zsPC3v8KRwrwhJusNClx27yCJ1jT4SbL vVdLDqJ3iru5lv8HivbOcgdbf22ugDbclVKT/rik3CzRSnYk7RtXztQyDoL7dSVsAbVh VLq+JhaGSqlzBQuADGV6mQ8/1qV6/liopqHXtbQ30LLKyVNEsYdiEJ3+75bMrEuX5xdx qSB6upGyPNDV5k0Yx27nPpRTM+gdqgIfsGoKriy6rVWZdf2zx/7qjzrVmU0RXcjEZLN5 SIJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:dkim-signature :dkim-signature:from; bh=a//Ayf6Cd8/CsHAT40buAmbBeRMSfyUjelkzghG9ajI=; b=mcdGD7qyj8OyD3KsHbXkBJTQPvMlS8j3LpxC1XShyaAdK5w0wltKk6T19dGyMWSRuu R5o33HVZKOnyrOrxZxIochxSwmYVMs5EW3D3e3Npzs8bGa2PI6+oOM8VAQuKk4jkHYBj bSIAc1vKdeV99jccRf+wYi0OotF92WZtN5WZLOhLJB+M0xptXIByPP9h1y104iL+0Pln OR2v8PP4jHP7GphVa4WYWh9UalRsvhA1TDICm2cKXRw21wPlbrromMEFryRA1Ted3Y1O 4TZNyIVuzH9Q+9V9rZoBMPE2st1z/BFdJgPA/vGccXvqHJG1l/0HeXsrvMyhTtHNBjAQ z9Nw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=lPl+ddht; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t17-20020a056a00139100b004fa3a8e0032si262803pfg.233.2022.04.14.18.15.07; Thu, 14 Apr 2022 18:15:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=lPl+ddht; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241628AbiDNJUu (ORCPT + 99 others); Thu, 14 Apr 2022 05:20:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40848 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241167AbiDNJUi (ORCPT ); Thu, 14 Apr 2022 05:20:38 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3483E5130A; Thu, 14 Apr 2022 02:18:14 -0700 (PDT) From: Kurt Kanzenbach DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1649927892; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=a//Ayf6Cd8/CsHAT40buAmbBeRMSfyUjelkzghG9ajI=; b=lPl+ddht5blVzHrAnBdE9KsqTJEZMbBs0aOx2oy1+AV63uIVl5VCDZGsaUbQUgh5+602Xh YTLzkz+i7NNfx7nXFZCglWU8lNN3NDultV74pP+5pecZlhtvV+EiKvrfuZ2fDrrPHi0gV5 0sjY72QxhIReM/h561J/9Mau/6QWDNFcQRhBij6NMmS962JPLyp2sByPQvDC256N7/I0vb mQ7dR5oWOqGl4RUTVmCuStRdmlaVP+syP0VtT6bP828RCyersvUWEkdfP8FSq9I+TXIA3e 5goKc1e6Vde7XzInYq7EIy0uUbzlrsmAOR8s/rk9x4ZNAuxrMkt/7Ze8o81yHg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1649927892; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=a//Ayf6Cd8/CsHAT40buAmbBeRMSfyUjelkzghG9ajI=; b=CZ70hXWPP5URIE/vjVomUR7Egh4Nlo9mlKYwmbtQlb1yGW1SflMkNwffgoxYuBmo0hfQcQ t0JUfnZoDEHbsgDA== To: John Stultz , Thomas Gleixner , Stephen Boyd , Steven Rostedt , Ingo Molnar , Jonathan Corbet Cc: Richard Cochran , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Kurt Kanzenbach Subject: [PATCH v2 1/3] timekeeping: Introduce fast accessor to clock tai Date: Thu, 14 Apr 2022 11:18:03 +0200 Message-Id: <20220414091805.89667-2-kurt@linutronix.de> In-Reply-To: <20220414091805.89667-1-kurt@linutronix.de> References: <20220414091805.89667-1-kurt@linutronix.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 --- Documentation/core-api/timekeeping.rst | 1 + include/linux/timekeeping.h | 1 + kernel/time/timekeeping.c | 17 +++++++++++++++++ 3 files changed, 19 insertions(+) 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 ) These variants are safe to call from any context, including from 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..2c22023fbf5f 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(data_race(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