From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 6DA162609FD for ; Thu, 21 May 2026 06:35:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779345337; cv=none; b=fbf2RVbbTWKh7SlJd+ewi8d9+nPjdz7kA5fCvCHLV3xVKKml/Oy2D7gmM66fpgfn3fqq3JUKSinxhCpMTZs6KaAHF3BlQpM/niZOeFYSBOT3Ej38/rqj7DKtOfFXP5eSgEh/FYOEwc2IKUY3mhdkJmv14UdUtlYI9u4Bb/yEYBk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779345337; c=relaxed/simple; bh=wbHChfYpS7xZBMGK8+RY2NG72BO9ecBhfwVliLAX/YM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=a8BmRmrFBLPqJs/ReBrM8stsHdLxk2AX9JDwosmlLyE4gteuqevsekqIUJcFkMP72Yxdw/IyLn/6FeDKenwEwmTDHo94veTVop7JZ1keq5DHla6qCuPwzxR4i4GXSwbYtwo5cJB9wfeO9d3Z403GwhlF6oyaC2L8/QcV/xKVvSg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=FEnVFiqs; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="FEnVFiqs" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779345335; h=from:from: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=e01YKGBIp76cxGi6O9YdR4xI/KS17BHEKhc6BaoTLvA=; b=FEnVFiqsbD7gm57sQNxrHOc6GLnx2644qBS4eySKYjCnKvihD5957u3dRjTWvnUX+WuBlr F+Rs0DYpPbDXMl/bQAl3rdq6e1KOg9jJNZjnk+CfofdmBCYByXomWzrWq+P2k2Xa/xbk/V tS4rxcppiAUH+3geF1JRYTnKCYzkdnY= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-591-rIIII_8xMg2CLcnVEqMEWQ-1; Thu, 21 May 2026 02:35:32 -0400 X-MC-Unique: rIIII_8xMg2CLcnVEqMEWQ-1 X-Mimecast-MFC-AGG-ID: rIIII_8xMg2CLcnVEqMEWQ_1779345329 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id C7CB819560A2; Thu, 21 May 2026 06:35:28 +0000 (UTC) Received: from localhost (unknown [10.43.135.229]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id DB4DC1800352; Thu, 21 May 2026 06:35:21 +0000 (UTC) Date: Thu, 21 May 2026 08:35:19 +0200 From: Miroslav Lichvar To: David Woodhouse Cc: Richard Cochran , Wen Gu , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , John Stultz , Thomas Gleixner , Stephen Boyd , Anna-Maria Behnsen , Frederic Weisbecker , Shuah Khan , Peter Zijlstra , Thomas =?iso-8859-1?Q?Wei=DFschuh?= , 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 Message-ID: References: <20260517220326.4625-1-dwmw2@infradead.org> <0d32da75fa88c92ac0225ef23a9045afdf2ac9fe.camel@infradead.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 On Wed, May 20, 2026 at 01:21:46PM +0100, David Woodhouse wrote: > On Wed, 2026-05-20 at 12:39 +0200, Miroslav Lichvar wrote: > > On Tue, May 19, 2026 at 04:50:41PM +0100, David Woodhouse wrote: > > > The design has two major purposes: > > > > >  • Avoiding the redundant work of having *hundreds* of guests on the > > >    same host *all* calibrating the same underlying oscillator, while > > >    enjoying the added fun of steal time as they're trying to to so. > > > > But isn't that work still duplicated, only moved to the kernel?  > > Not the actual calibration of the TSC against real time, no. It is the > *host* which gets the 1PPS signal and does all the work of tracking and > smoothing the frequency drift over time. The guest basically gets the > same as a vDSO, *telling* it a relationship from TSC to real time. Ok, but I don't see why the phase corrections of the guest need to be in the kernel. > > I don't like the idea of adding more clock control loops to the kernel > > much. > > I completely agree. I am absolutely not planning to add any more clock > control to the kernel than we already have. As you say, we probably > have too many already. If the vmclock driver is feeding the PLL with the offset between the host and guest clocks, I think that would count as a loop. > I'm not sure what scaling the guest TSC would buy us. Sure, it would > minimise the frequency step at the moment of migration, but a naïve > guest which isn't using vmclock's disruption signal is screwed on live > migration *anyway*, because there's *also* a step change in the actual > TSC value which is bounded by the real time synchronization of the > source and destination host. The TSC offset can be corrected too. I thought that was already happening. > AFAICT scaling the TSC would just add complexity and wouldn't help > much. I think it's a better place to be solving this kind of problems. It's compensating for a hardware change. It doesn't need to happen only at migration. You could adjust the frequency continuously if you really wanted, kind of like synchronous ethernet is doing for clocks over network, improving the stability of the physical clock and phase corrections are done on top of it at a higher level. > And TSC scaling is pretty much x86-specific; other architectures have a > *defined* counter frequency and don't need to support scaling. There can be a software fallback if hardware scaling and/or offset is not supported. > > > > There is a work in progress for chrony to support MONOTONIC_RAW as the > > > > main clock. It would be nice if that could be corrected in migrations. > > > > > > Not sure I understand this. I thought the whole point of MONOTONIC_RAW > > > is that it *isn't* skewed by NTP? > > > > It isn't adjusted, but it can be used as a stable reference avoiding > > the multiplier-induced jitter, interference from other processes, and > > synchronization loops, e.g. when an NTP client is synchronizing to an > > NTP server running on the same system (in different containers). > > We could just use the TSC for this, insted of MONOTONIC_RAW, couldn't > we? > (for TSC, read 'arch counter, timebase, etc.' — none of this is x86- > specific but 'TSC' is quicker to type...) Meaning userspace would have to duplicate the kernel's handling of the counter (wrapping and scaling) just to avoid a single multiplication in the vDSO? -- Miroslav Lichvar