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.133.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 E7ED23C0601 for ; Wed, 20 May 2026 10:40:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779273611; cv=none; b=Yp0ADrE2C6rsroxvEQck84sh3pXU/ulUzTQaFygo8qSzzaIE1yhW8hCRqgQaEA7vvpKH+gIH/DXRL9bRyOm83bdYyaWl/H3zucvtr413736M08yq5pOu3BAhhmvSM1HwFzFEA/+JkUTzpgEFBBsD/Ia+Ga0hqtDTUIQYmod1E4M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779273611; c=relaxed/simple; bh=x9dya+ZNYzOVdkxf75Rrn48VtlhjcIvxhGXaPQ1/Gfg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KeFfv/SUjJy68+mcfvHHRBQ22zpFhtOQAsicHyHc9a/HVlBdvPi0jGuww3yA1kbHi7gA9Bxx6yz1XY3tchOrR0MOP3nu6/fftcpgYlzmS3I/g4x4vd0UgWU8lcXKychF8hqBA14p0r08ayG/j7Ob/fzLxFq3p+/Vz1AhIC4vTzQ= 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=QdEjXbPu; arc=none smtp.client-ip=170.10.133.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="QdEjXbPu" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779273606; 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=qQz7fbw8O5dAlENqPmHtsGTxVrcWzvfxH8z8wu3/9VI=; b=QdEjXbPuYHzpOy9z7kYD+RH2krXKxYH8g4Ipmh+KGs3koHFisCzYm1s2DsjwP311M+vuVa FqKeF6GnC1oxk5kephWUZiIOFZWfrFE7ENHHHKhohzHbtqwtnnXIEYjbAPPcImArxYbHxY gD/HrTvPJJYLsBdA2vssr7VdoAcFop0= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-144-FgjzAl7BPTCozZ2Q6Xid8A-1; Wed, 20 May 2026 06:40:01 -0400 X-MC-Unique: FgjzAl7BPTCozZ2Q6Xid8A-1 X-Mimecast-MFC-AGG-ID: FgjzAl7BPTCozZ2Q6Xid8A_1779273599 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A8ADF1800619; Wed, 20 May 2026 10:39:57 +0000 (UTC) Received: from localhost (unknown [10.43.135.229]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 5E97A1800673; Wed, 20 May 2026 10:39:51 +0000 (UTC) Date: Wed, 20 May 2026 12:39:49 +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: <0d32da75fa88c92ac0225ef23a9045afdf2ac9fe.camel@infradead.org> X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 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? The userspace part could be a simple loop waiting for vmclock notifications and following the changes of the host. The only difference would be a longer delay, but still insignificant for the intended purpose, right? I don't like the idea of adding more clock control loops to the kernel much. It's a complexity that will likely grow as different requirements come and the code will be even more difficult to understand. IMHO the NTP PLL and hard PPS loops shouldn't have been included in the kernel. The kernel time control API should have been just setting/stepping the time and changing the frequency, both possibly at a specified time instead of the time of the call. > > Have you considered a different approach that would address the > > problem with frequency step by adjusting the guest's clocksource > > frequency to match the original host? That would correct all system > > clocks, i.e. not only REALTIME/MONOTONIC, but also MONOTONIC_RAW and > > AUX clocks. > > You mean TSC scaling to change the frequency of the actual counter? Yes, in hardware if available, or in software if not. An additional 32-bit multiplier applied like this: cycles += (cycles * mult) >> shift Larger adjustments can be done in the normal multiplier for all clocks. > When stepping between non-identical hosts, that might be helpful. But > we still have to deal with the variance of the counter over time even > without migration in the picture. Whatever is synchronizing the guest clock to the host (using the PHC or vmclock page) will take care of that? The point is to avoid migrations causing a frequency step. I'm not sure what identical and non-identical hosts mean in this context, same nominal CPU frequency, or a CPU tied to the same crystal oscillator? > > The guest would still be in control of its clock and follow its own > > preferences to stepping, maximum frequency errors, etc. It could still > > compare the stability and accuracy of the host's clock and use it for > > synchronization only when it's actually better than other available > > time sources (some VPS providers are known to have poorly synchronized > > host clocks). > > I think that mode is already available as a PTP clock, isn't it? Yes, but it's slow due to missing frequency transfer, not feed-forward as you call it. The host's frequency offset could be exposed in the PHC's timex. > > 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). -- Miroslav Lichvar