From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D26AB18DB2A for ; Sun, 24 May 2026 15:05:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779635113; cv=none; b=qgPUMgfO5TvuHnhVf1ARRJuXPms1axA7YRbqqfoopJTeu+jD04prKmrVUIzYHmreINzafBFLM0Iy8EDVxkaV0OABm8t1XO8e/JbyBsHyENn23vwA6hBW4TBtnb5fv6httKEH2digus3TCKvXn2WfP87As8lc1y4agcwAAJxgwqs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779635113; c=relaxed/simple; bh=ZFfH5jKZr1PcJ6Pg5BUs3fd5EiU2ihhAZBYV3JatHgo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=i7SRQ43Pugb6wBp9UoeLbyD6aPC6SjBop75sHroNvtCeX/v8SOqeiqAgJVCZzt/BPrr6qrqbQ9y94bQvwroTllP/XWDfkeaLFygghiDaG4RqGJH6KOP9Rrsg+C6I054kueDuczC08TYxY0uVQnY2ELB3axdrGdNeLCB/pHI4Nro= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=U1t4b/FB; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="U1t4b/FB" Received: by smtp.kernel.org (Postfix) with UTF8SMTPSA id A46F41F000E9; Sun, 24 May 2026 15:05:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779635112; bh=3DNcCsf9M1msR/MDu3ObPFXV3vkmsntK7q2YPkO67rI=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=U1t4b/FBcRqeLh8xKshAN8PpkYUqyqKTE5PN4ntc6nyBDnZHieWwZ5ZU38mgAROai +mOXBQFOxO+TJAQiLL/AN6LvTYrAl3jxU2dscslZVTE6tIykiDgi+Rh2iSopooO6sA gkuksxqX5Afr1Hubg9BfrePkddGedE2HoWG0JpTT8/BMm319Iv0q0hPU9wX1gnmVsy r6ilIuc3PeYi99nvP9uFPmZHdL0QB7wE5YPOku2f1Hxv6omjoKx89GW1Q8a750cvLk 9/JOtMzp3QQgQ+Ad8rpR4428DGKfxCfePTpblppMhaHCsDbdJc42Wi9xvhrdTNCW5W R9kB29mSr43Ow== From: Thomas Gleixner To: David Woodhouse , Miroslav Lichvar Cc: Richard Cochran , Wen Gu , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , John Stultz , Stephen Boyd , Anna-Maria Behnsen , Frederic Weisbecker , Shuah Khan , Peter Zijlstra , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= , Arnd Bergmann , Julien Ridoux , Ryan Luu , linux-kernel@vger.kernel.org, Marcelo Tosatti Subject: Re: [RFC PATCH v2 0/8] timekeeping: Fix draft tracking precision and add feed-forward discipline via vmclock In-Reply-To: References: <20260517220326.4625-1-dwmw2@infradead.org> <0d32da75fa88c92ac0225ef23a9045afdf2ac9fe.camel@infradead.org> <87o6i8vcni.ffs@tglx> <6c7137748ccea288fdf55e7c2e24817ccc1673ef.camel@infradead.org> <874ijzvpl8.ffs@tglx> <00609fa255442648e11e2b5596a3b80a29edcfc8.camel@infradead.org> <87v7cftqey.ffs@tglx> <87se7ht25o.ffs@tglx> Date: Sun, 24 May 2026 17:05:09 +0200 Message-ID: <87mrxou9ui.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Sun, May 24 2026 at 14:13, David Woodhouse wrote: > On Sun, 2026-05-24 at 14:36 +0200, Thomas Gleixner wrote: >> > But on the other hand, can't the conversion be a whole lot simpler than >> > get_device_system_crosststamp() because it's not actually dealing with >> > any timekeepers; it's basically only invoking convert_base_to_cs()? >> >> But what for? If you have PTM, use PRECISE. There is _zero_ value of >> having pre/post timestamps when the hardware already does the correlated >> precise sampling, no? > > The PTM mode and support of PRECISE (or the variant) is currently > fairly esoteric: very few devices support it. So I'm not sure we should > expect generic userspace to always even try. There are not so many PTM capable devices to begin with. And yes, user space which cares about time and accuracy _should_ try it. > So there may be some merit in having EXTENDED use the precise hardware > paired timestamp. Maybe we don't necessarily care about returning > *cycles* but if we *do* use a PTM-capable device (and I'm including the > virt TSC-based ones here too), then we kind of want the ABA *all* to be > at the same clock cycle. Which is what I've already done for vmclock. If you can do ABA at the same clock cycle, then just implement the cross timestamp callback and use that. For PTM capable devices which lack cross timestamp support in the driver, adding the magic PTM value field in the ABA timestamp won't make it magically be filled in. So someone has to touch the driver anyway and then adding the actual cross time support is not much more effort than adding support for the new field in the extended callback. Also user space which wants to use the cycles stuff needs to implement the new IOCTLs anyway. The cycles won't show up magically in the existing IOCTLs either. So if you make the data struct identical, then it's really not rocket science to try precise first and then fallback to extended. Actuall with the identical data struct you could make that _ONE_ new IOCTL and the kernel uses cross time stamps if the device supports it or extended if not. All it has to do is to report the choice and therefore the number and nature of the samples back to user space. Not rocket science either. But in both variant (separate or unified IOCTL) user space has to handle the data sets correctly. No strong opinion on that as I have no clue about user space :) Thanks, tglx