Received: by 2002:a05:7412:2a8c:b0:e2:908c:2ebd with SMTP id u12csp3939360rdh; Fri, 29 Sep 2023 06:55:10 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF0fprbw4yMxcaWVDkxc2mo/XeVxhZvGgiamxHUEM0nrGcN0kHkS9oT+LI9mFJ4Iai9j/Hr X-Received: by 2002:a17:90a:bb82:b0:277:3569:29fb with SMTP id v2-20020a17090abb8200b00277356929fbmr6760594pjr.11.1695995710200; Fri, 29 Sep 2023 06:55:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695995710; cv=none; d=google.com; s=arc-20160816; b=TIIoq5G7q6gBNM9jZlkHWVptwcfoH//6zl7u+85vBKs27bwLAOXHmC0wafzaLVG2o2 M6MjjUEcPraLVBCIhKKTOLzRUgD3D6OIEvnjrFW2YnF5XTy/po1/BUzMboDmrIX0OkiB KrwS0tx4NSKyQQH50blSo7wStMUrlEUgtqauYJB5mhzS09xkfpxNeFgt5ICW0qkXA7zb E0X0hSg2jjgwyCP+stp7c9U+D6VqX8v5YrKTZXY6e05mha1GEK+hxvT2j1RT7XdNpyEa zxB83Y8JkEYtp/dVjsAg4smrGhu2QHnS4CGZYCbnE5IpFHcEwsxu+NKHP2seUDuY1FIO UWwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=q5nybL4dvTURYZgr23LqoAjNxEI6cIl7C36UD+zafSo=; fh=GYVwUuEyzEaEZK3zIRhRsbD53X9sppHYvicbzmiS8PQ=; b=pLVO9znIwKpyX3ZlNQA0d8Fy9+3i3nO/YFX9GdswtgR1fUcucsm3+JAq006npNMwOF /n048ewak77aMWgo8UgN24xXx9+nCUIyafEHYhKTdcGX68lSVBoaqGbDDdJmyMWzczez vvl/n6lWfQEqEUthiZyvWFiSxl9lQiJUJkzonad+MGDTKUGkyfIPpslMxO5oCU6xRvG2 Mu/7QclMP+WCffqx5uurEQIu9xrPQmNQzHernAASaEt99DZutIlCdVw0F9UwofoRrWGK 9iG9FJ+Y1J85Ra507MLNKS48GOXWEm+F9WkViwBcvLwM2uhPwBMq9JozQ7mak+51fzxH 6QZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b="MxK/gmz1"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id g12-20020a17090a9b8c00b0027717627cf6si1633233pjp.41.2023.09.29.06.55.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Sep 2023 06:55:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b="MxK/gmz1"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 1DF1982F34A4; Thu, 28 Sep 2023 23:57:08 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232613AbjI2G5E (ORCPT + 99 others); Fri, 29 Sep 2023 02:57:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52722 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229754AbjI2G5C (ORCPT ); Fri, 29 Sep 2023 02:57:02 -0400 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 85FC81AB for ; Thu, 28 Sep 2023 23:57:00 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-4053f24c900so40335e9.1 for ; Thu, 28 Sep 2023 23:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695970619; x=1696575419; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=q5nybL4dvTURYZgr23LqoAjNxEI6cIl7C36UD+zafSo=; b=MxK/gmz16h8Y7usf0+eDPOpOPRbUE6Q0xZHUBWDBBGZsfpsmtCRW5i9gInQPXkA0DT v8ViqKLIlixp/TNp6PM4aTdvAFYVI7U43yTlm9V1VqFRukXumo8xBa8iT1bHcBZNClNi RtNw0ORsjEqK743kggR9BP9B0vsQ67k14ZTI4cIEx+fo79e0W8DG2zOttpBdQCPNibkg L1BZAXfk7irLt3Wi116JLDSmvfUowFBpsaA4t0gQ1Xk2SA3iInBSSesgm5QbjBd1pOYL tE3VCHKcEBUq6k9Si9f8G1xhA//+SEsw0wIpKWWXibRIgwOI0wZJeAaxAr+VHG7Of9Hp /CKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695970619; x=1696575419; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=q5nybL4dvTURYZgr23LqoAjNxEI6cIl7C36UD+zafSo=; b=FYwWdzPWbkFo0MveiqDOm8Ei4sTQvv0XVkFjZeEXfYNdcMC2VlNGJAxUd7Zt1khAYT KHjg+HmAErBXLPtempgQfi/eXKEDMAf4OLpHN+vEYEbWd2ev6DG7vJJX/onc6h/FtbCl CimMfv+6QBELAewP1tj+MaKt8Upbza8ev1gmXC+YOdDjrslvbxsrqRMz3If5a35fad2D cguwPLUYxFxKaj4/BuLp8N6IzCTs6grlbd67dZi3DwZAcJntJ1dS7ptEqb+DQwsD/w89 tR7z2gkUDMFVwpg6EhREGvN4JznSEkmD25OvsDPp7Z/kqjr0DQgRwS0kMc6bnq3NQYFP sCnA== X-Gm-Message-State: AOJu0YyGRslDMYUhwC4r4n/J4K6Lz2dUGWZp69L08G3fYSgzloPLP8wK W00CBmk3DABsv8Ao1oIX/VJ44ys946uPFjmOtZin X-Received: by 2002:a05:600c:34c8:b0:405:38d1:e146 with SMTP id d8-20020a05600c34c800b0040538d1e146mr443186wmq.4.1695970618685; Thu, 28 Sep 2023 23:56:58 -0700 (PDT) MIME-Version: 1.0 References: <20230929023737.1610865-1-maheshb@google.com> In-Reply-To: From: John Stultz Date: Thu, 28 Sep 2023 23:56:46 -0700 Message-ID: Subject: Re: [PATCH 1/4] time: add ktime_get_cycles64() api To: =?UTF-8?B?TWFoZXNoIEJhbmRld2FyICjgpK7gpLngpYfgpLYg4KSs4KSC4KSh4KWH4KS14KS+4KSwKQ==?= Cc: Netdev , Linux , David Miller , Jakub Kicinski , Eric Dumazet , Paolo Abeni , Jonathan Corbet , Don Hatchett , Yuliang Li , Mahesh Bandewar , Thomas Gleixner , Stephen Boyd , Richard Cochran Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable 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 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Thu, 28 Sep 2023 23:57:08 -0700 (PDT) On Thu, Sep 28, 2023 at 11:35=E2=80=AFPM Mahesh Bandewar (=E0=A4=AE=E0=A4= =B9=E0=A5=87=E0=A4=B6 =E0=A4=AC=E0=A4=82=E0=A4=A1=E0=A5=87=E0=A4=B5=E0=A4= =BE=E0=A4=B0) wrote: > > On Thu, Sep 28, 2023 at 10:15=E2=80=AFPM John Stultz = wrote: > > > > Thanks for sending this out. Unfortunately, I'm a bit confused by > > this. It might be helpful to further explain what this would be used > > for in more detail? > > > Thanks for looking at this John. I think my cover-letter wasn't sent > to all reviewers and that's my mistake. No worries, I was able to find it on lore. Though it looks like your mail threading isn't quite right? > > 2) Depending on your clocksource, this would have very strange > > wrapping behavior, so I'm not sure it is generally safe to use. > > > The uapi does provide other alternatives like sys, mono, mono-raw > along with raw-cycles and users can choose. Sure, but how does userland know if it's safe to use raw cycles? How do we avoid userland applications written against raw cycles from breaking if they run on a different machine? To me this doesn't feel like the interface has been abstracted enough. > > 3) Nit: The interface is called ktime_get_cycles64 (timespec64 > > returning interfaces usually are postfixed with ts64). > > > Ah, thanks for the explanation. I can change to comply with the > convention. Does ktime_get_cycles_ts64() make more sense? Maybe a little (it at least looks consistent), but not really if you're sticking raw cycles in the timespec :) > > I guess could you clarify why you need this instead of using > > CLOCK_MONOTONIC_RAW which tries to abstract raw cycles in a way that > > is safe and avoids wrapping across various clocksources? > > > My impression was that CLOCK_MONOTONIC_RAW (as the same suggests) does > provide you the raw / undisciplined cycles. However, code like below > does show that monotonic-raw is subjected to certain changes. > """ > int do_adjtimex(struct __kernel_timex *txc) > { > [...] Err. The bit below is from tk_setup_internals() not do_adjtimex(), no? > /* > * The timekeeper keeps its own mult values for the currently > * active clocksource. These value will be adjusted via NTP > * to counteract clock drifting. > */ > tk->tkr_mono.mult =3D clock->mult; > tk->tkr_raw.mult =3D clock->mult; > tk->ntp_err_mult =3D 0; > tk->skip_second_overflow =3D 0; So the comment is correct, except for the tkr_raw.mult value (I can see how that is confusing). The raw mult is set to the clocksource mult value and should not modified (unless the clocksource changes). > """ > and that was the reason why I have added raw-cycles as another option. > Of course the user can always choose mono-raw if it satisfies their > use-case. Having raw monotonic as an option seems reasonable to me (as it was introduced to provide a generic abstraction for logic that was using raw TSC values in an unportable way). But the raw cycles interface still worries me, as I want to make sure we're not creating user visible interfaces that expose raw hardware details (making it very difficult to maintain long term). thanks -john