From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 58D1D283FEA for ; Tue, 24 Mar 2026 17:34:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774373657; cv=none; b=A9Y6H+09TmJQ5+nR2r1b332WGkCAk88y2DfZMjaQGS8iY3aA5mrPjZgvIPWD08LhOrev075DJLoPOCwjnyMEDIkAjKvdEYFJ41E4ulJ93GSk0WujwOX/py1qK4GuMiCpywzK2tIsSkaQDDGPkDCeuOAuVtX/pJJ8Qpsh6hDXFtw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774373657; c=relaxed/simple; bh=QOnrzBCkrEloosOd9xfQ4ckOJi+hcKjohoLniV/izTs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CBIhbXxF6wnXdlmdJxVvrTzMsSjzquiC5JrHSdHNLoFhz2cPQY3jva6IGA+9BYZJo6oMMNhKtXvO4ilySSNkt6acNSl8h20Tw6dH8sBOY2BKX0IBsapHbyFq2ban8UKN4gZFhhtp+X+QH0yePBaHPoXQn4NF5Z4nBV3jOemO4L8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=rqyH7/hV; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="rqyH7/hV" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=yVqjEQQQfM5ciBFNK3wv9/7pQI65LlKRGk0cgGdmDlA=; b=rqyH7/hVETqxCni4KWQ3fwGPXJ 9el8cGs898rLo7/cjBKRFfKnKfnsVYUjKVLlUWO8S+GiuEG3z1iGW0WXzhnWTIpt/k7z94a0A4VP9 Put0ulYidmj8ISNKo0DwAhlF6eC3rgRbv6gamWvjuHSngayKdq1mxNkZujZhNq7QTCxYiciiWgqzg De41w/F0PUBeTJ0V6oyyMLvAS+Xn56ZooBK63A/ljXfOJ+T0bgohyDBnEJz2Zc8zg0Mw2Y22E1BEX geZz5yoar/A7wzyTV/ZgzL0yjlch5FhAMkoVjP9Xpe+VNd/LLDU6nd6JKSmeJXZidp+jIkYfDCN7I Q5e3MvXw==; Received: from 2001-1c00-8d85-5700-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:5700:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1w55dn-0000000ENsT-0LCE; Tue, 24 Mar 2026 17:34:07 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 9B1A03002D8; Tue, 24 Mar 2026 18:34:06 +0100 (CET) Date: Tue, 24 Mar 2026 18:34:06 +0100 From: Peter Zijlstra To: Thomas Gleixner Cc: Michael Kelley , 'LKML' , 'Anna-Maria Behnsen' , 'John Stultz' , 'Stephen Boyd' , 'Daniel Lezcano' , 'Juri Lelli' , 'Vincent Guittot' , 'Dietmar Eggemann' , 'Steven Rostedt' , 'Ben Segall' , 'Mel Gorman' , 'Valentin Schneider' , "x86@kernel.org" , 'Frederic Weisbecker' , 'Eric Dumazet' Subject: Re: [patch 19/48] clockevents: Provide support for clocksource coupled comparators Message-ID: <20260324173406.GA1850007@noisy.programming.kicks-ass.net> References: <20260224163022.795809588@kernel.org> <20260224163430.010425428@kernel.org> <87v7emgrd5.ffs@tglx> <002301dcbb24$4825b600$d8712200$@zohomail.com> <87cy0tgmyn.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; charset=us-ascii Content-Disposition: inline In-Reply-To: <87cy0tgmyn.ffs@tglx> On Tue, Mar 24, 2026 at 06:24:16PM +0100, Thomas Gleixner wrote: > On Tue, Mar 24 2026 at 03:37, Michael Kelley wrote: > > This approach is not as general as Peter's, but it covers the Hyper-V timer > > case, and is simpler. The cost is an extra memory reference in > > arch_inlined_clockevent_set_next_coupled(). arch/x86/Kconfig can continue > > Which can be avoided with a runtime_const if the decision between hyperv > timer and tscdeadline timer happens before either of them registered the > clockevent and does not change later on. If the wrmsr immediate form is faster (that was their purpose) than the current form this will no longer work and we'll have to get more creative, but yes, until that time this should work.