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 5D4F122619 for ; Tue, 28 Jan 2025 19:30:29 +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=1738092631; cv=none; b=eIIrv2qmf6Cglg2aNMubhXe8i8KZS+m+gFvUGfUFsk5ICl10tKAF9W2p8ttNmbs/w8oqaYtW7HU406mCJtPd0wXAbfKhKwNE82JCU2r3ejfn5TfTw0ZxgTKOb97zpbACqLcVDNItLV6ws6SrE6yTORg1z01CNXo88c1dD70aWG8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738092631; c=relaxed/simple; bh=ZjgrxzZh7WyU2mpMjmaGdk2L8UlF7PbEhAe0YAKuNzU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GsHhoUpOSmhwy/mNpgXgMeaFzKZKVVWeJd/x2mYsacJJF0SlpfOTGBWOKZMXuaEb3gBkEwG7Iiw/7kFbzUol4H00zFsK8FWMSDY5scYkkjeCak7emcaZ3viFR3Ostqdu/6xzG1KngZmkWCIyTEHaWcqxA8CmgZUmTOC/ALqUFsk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (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=LHvYMd2D; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (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="LHvYMd2D" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=r76U9tjRnF/SiGGSz+v1CkQ81KDX6kfTfWpm6rstywM=; b=LHvYMd2Db5YyvDr71J4y8fhxsu BIH5yXYhEdCuBtn+u2tyf0GnJRlOScHdnYnT56A2cqgh9WlHlJFlIllajlSTjlqI0MBFmM2azA8gg RYOSeCfj2N/s86lqyJ6V8xpczECHVwAaooDhBvfFj6mYQHOeERM2IAmMopBiJm/RKkQ//nXxsSeV+ vI/G+hkNDgc06ux/MlVNFmu1y5J6DTmqm/3F31DX5H7yNpjRU7F2ZQMxrcA0R/q3XLrVWaOSwPiTs yyFJOZhDoOikYrtijAOVfHBgP/Qs0cgk8Bg6s/F+pxX0PBPboJbCF3x2NHcphq3CAFXfVAEJyv7OA 6BjSlFZw==; Received: from 77-249-17-89.cable.dynamic.v4.ziggo.nl ([77.249.17.89] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux)) id 1tcrHu-0000000B1vG-21zg; Tue, 28 Jan 2025 19:30:18 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id C246D30050D; Tue, 28 Jan 2025 20:30:17 +0100 (CET) Date: Tue, 28 Jan 2025 20:30:17 +0100 From: Peter Zijlstra To: John Stultz Cc: LKML , Anna-Maria Behnsen , Frederic Weisbecker , Ingo Molnar , Thomas Gleixner , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Stephen Boyd , Yury Norov , Bitao Hu , Andrew Morton , kernel-team@android.com Subject: Re: [RFC][PATCH 2/3] time/tick: Introduce a dyn_hz boot option Message-ID: <20250128193017.GE7145@noisy.programming.kicks-ass.net> References: <20250128063301.3879317-1-jstultz@google.com> <20250128063301.3879317-3-jstultz@google.com> <20250128090737.GX7145@noisy.programming.kicks-ass.net> 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: On Tue, Jan 28, 2025 at 09:29:30AM -0800, John Stultz wrote: > On Tue, Jan 28, 2025 at 1:07 AM Peter Zijlstra wrote: > > On Mon, Jan 27, 2025 at 10:32:54PM -0800, John Stultz wrote: > > > +#ifdef CONFIG_DYN_HZ > > > +extern long long dyn_tick_nsec; > > > +#define DYN_TICK_NSEC (dyn_tick_nsec) > > > +#else > > > +#define DYN_TICK_NSEC TICK_NSEC > > > +#endif > > > > My git-grep TICK_NSEC spies a whole bunch of TICK_NSEC users that seem > > sad now. > > > > That is, why don't they all need updating? > > Thanks for taking a look, Peter! > > So TICK_NSEC is still the length of the HZ tick. The idea with this > series is we're leaving HZ as a high frequency, but then just > programming the interrupt to come in at a lower frequency. That's word salad. Either the timer is slower, as alluded to below, or it is not. It can't be both. > So it's only the logic involved in setting the next interrupt, where > we need to use DYN_TICK_NSEC. In other words, the actual interrupts will happen dyn_tick_nsec apart, not TICK_NSEC. This means that pretty much every TICK_NSEC user in kernel/events/ is now wrong. They're assuming the time between interrupts is TICK_NSEC -- we even inhibit NOHZ for perf to ensure this. Really, you need to audit each and every TICK_NSEC users at the very least.