Received: by 2002:a19:f614:0:0:0:0:0 with SMTP id x20csp33382lfe; Fri, 15 Apr 2022 18:06:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzI7TIZlFEfO39wV5jYTCh66l9yh0AQ9wv0PNEhSJGQDfRJU5f8r/cc+ZvuhSdZES6sfOjP X-Received: by 2002:a17:903:2482:b0:158:9173:ddd2 with SMTP id p2-20020a170903248200b001589173ddd2mr1586631plw.22.1650071165164; Fri, 15 Apr 2022 18:06:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650071165; cv=none; d=google.com; s=arc-20160816; b=zYPzDrbVElGDPNev0oq1hF4+yRGmhCgECVJU74dY8+hTyHfhADKRd37xOARgAranVY T+l7+0etzMWDXi9j0yqrWkgsm3Abjb13aihAUt7WbwEPfn7TksMVLWoflkcQe0M2aUI0 eMtzjcnhqOpNF1+OUrNRq9KPLmO/ox3mP3afh8UDjZUhMGeA7XDJuDMN/sswOgpJhKel l8ihjwMKr3MMz771lBw6+RUu+K/0JsdHrq0E8aG8txffXhilk1DLHxI1Olhh7ez+ByxJ mSaenijxb5l86h/i4CC/gnvAYXJVWf+ENo9mZIPzGfWvKxpqiCyLp3nfjgguaYyqi3Uc rh8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:robot-unsubscribe :robot-id:message-id:mime-version:references:in-reply-to:cc:subject :to:reply-to:sender:from:dkim-signature:dkim-signature:date; bh=5TDdmE09S+E9/Bqk8y91Y/tlKrElwL0r7vtr9lMqW9U=; b=1H9i+QQxiLMkGMrcnHMo8ePLw+gJ0a+jCDF4U3CvXXlHATS2lH1jZtnjEYOoAWrJsE MeD+Vgn/7Rc4ii/hpBWwWq0NI4OuYjwTVw8it0KUTxXyhwyNQLXgOj6y0CfSs/fk24m2 cugEiPmNuj3eg0OIP8LFIhlXAvKYn+2+TKt4UR1tZYCkZROZ+m2ate+zPJXZ/MTt/5BJ 81LruEkW3ikB0pXp2f4D+GgswWNlNoJr6lRCwjy9GDGaDYdwk/3GkQweRJVwFW2yPKeJ 7bkPe5D9EgzIgB6wJ1Ziv0+q2pmiCtmw25fDV1EkaSzKqMRgsqAYvosiwfAudggnkG1c dNPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=InGj8ELY; 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:18 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id p18-20020a170902e75200b00153b2d164ecsi2813109plf.244.2022.04.15.18.06.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Apr 2022 18:06:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=InGj8ELY; 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:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 61B671F63B; Fri, 15 Apr 2022 17:46:59 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359069AbiDNPmh (ORCPT + 99 others); Thu, 14 Apr 2022 11:42:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57558 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352594AbiDNPRk (ORCPT ); Thu, 14 Apr 2022 11:17:40 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B0FC9BC84F; Thu, 14 Apr 2022 08:01:49 -0700 (PDT) Date: Thu, 14 Apr 2022 15:01:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1649948508; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5TDdmE09S+E9/Bqk8y91Y/tlKrElwL0r7vtr9lMqW9U=; b=InGj8ELY5RkNkL8kloc8CDlSZ1y2WANocZcFCND+1ssigyWALFB/ng6WkUbYbXJiXTBhSL Y20HEGYHEaj+O77omc/5xrq2ww29MpLHuJSv28immg0A5mRJXC5Fl6d/IjNFR0Bsl1QTms CzgoC2WaQNS8SmFj+ViWq40toUj9gm40qvR7r2NgfjLaF1DsF/wntdG0keZU1oRx85HgOn JXKZ+Bx6zUKw3Y8be4BT64yNtaPbJIOCRp2qHvQkehR8PulBsI5mnTl1wYU4jQ5bQESC33 3EAlC9GRJWHGX9s+k+vDjjr7QnnndnCoNWvVwFy0JkWRM/JrB1ZXGVr+S7xhcQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1649948508; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5TDdmE09S+E9/Bqk8y91Y/tlKrElwL0r7vtr9lMqW9U=; b=3/uIJrS7WAhtmU1EGBcKtXPgShejbu9njwq0JTnjtLGRSPOWIF6NFxyVabVWlQBU5fWTgj lIh/ULi630BYpkDA== From: "tip-bot2 for Kurt Kanzenbach" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: timers/core] timekeeping: Introduce fast accessor to clock tai Cc: Kurt Kanzenbach , Thomas Gleixner , Steven Rostedt , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20220414091805.89667-2-kurt@linutronix.de> References: <20220414091805.89667-2-kurt@linutronix.de> MIME-Version: 1.0 Message-ID: <164994850704.4207.9058445142052855306.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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 The following commit has been merged into the timers/core branch of tip: Commit-ID: 3dc6ffae2da201284cb24af66af77ee0bbb2efaa Gitweb: https://git.kernel.org/tip/3dc6ffae2da201284cb24af66af77ee0bbb2efaa Author: Kurt Kanzenbach AuthorDate: Thu, 14 Apr 2022 11:18:03 +02:00 Committer: Thomas Gleixner CommitterDate: Thu, 14 Apr 2022 16:19:30 +02:00 timekeeping: Introduce fast accessor to clock tai 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 Signed-off-by: Thomas Gleixner Cc: Steven Rostedt Link: https://lore.kernel.org/r/20220414091805.89667-2-kurt@linutronix.de --- 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 729e248..22ec68f 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 78a98bd..fe1e467 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 dcdcb85..2c22023 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;