From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 23973194096 for ; Wed, 29 Jan 2025 08:09:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738138147; cv=none; b=MePhlF6IVBCmYKT6JCbx6jPdghpYV4y+AHjF1FuYSX3Q89HcVMmCCihaJETchlObLzUAzGBQKz90B0zQ1/toQa019uHhIeU+gEeV54sZZLQgWiPskvQlt8Q/M1TyjW8ZEuba9AD+qxRDhmA5qgBg7APlmZEWK9ct/suNYVQr/NM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738138147; c=relaxed/simple; bh=NBou9GU7q4xBJ0tU4HsU213czeOIPXUyAmFZZByMqsI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=fcgJ5Y2jJ1PWsyacc1wtqKfCKhszjJlQ96dh1RbGcRDPefXPnk4agTyCZsda1j7VLaqdMI9dLETu+pQlnLMiVxkpNJ+eO5zfLlwi3YxE53b4q0TcfAl3/gntROER7vX2IG+3HiuNOGMfMOkbEewj1LUNw9qeDoIrTu2spwsUwUw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=QNMOTNkB; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=vcW0nPjo; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="QNMOTNkB"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="vcW0nPjo" From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1738138143; 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=0MPLE3wtkhzYX7CUd5Y9rBpQ47FbuB6qLUG9GTTbHXI=; b=QNMOTNkBhtoO+zbqyTEjMPR4VTHxR4pzpIXVfAZ2E9a6sv1jm+QuWhKjfjLiqyx8px26g8 WqsM2HdphLar5n9LH/iE6k58EgNY/8O2fdCCIsgVpYqYXRHDlfTiy3h0d/ZgS5KYFxoWCW KYV06A88c+XtsC0TbqG6z4C2hgtOUzHoeneWAjjJOF1M8cqTBeTgt/oSwNQdPsu/9+/fEe gWU25tYczWrN0xNZ5g3Wy4mRov9wHftLm3EsQJpByFSU1+Y+sBx/t0faigZF7VUWxxM3ti 225VqPKycX9tCtR54iicqNTcpK9kRpFOxc4F25VkIh8Wm2OoMscRQAO8l/ECIA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1738138143; 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=0MPLE3wtkhzYX7CUd5Y9rBpQ47FbuB6qLUG9GTTbHXI=; b=vcW0nPjoXDyI82h2gXUBphaPNF9fHJGv7j58SGvf3rGeyDof8GuHCs3cUw+4DoncXaec5t 9WfeLxevA74XpJDQ== To: John Stultz Cc: LKML , Anna-Maria Behnsen , Frederic Weisbecker , Ingo Molnar , Peter Zijlstra , 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, Saravana Kannan , Samuel Wu , Qais Yousef Subject: Re: [RFC][PATCH 0/3] DynamicHZ: Configuring the timer tick rate at boot time In-Reply-To: References: <20250128063301.3879317-1-jstultz@google.com> <87cyg67up9.ffs@tglx> Date: Wed, 29 Jan 2025 09:09:02 +0100 Message-ID: <87a5ba6nz5.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=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 28 2025 at 22:10, John Stultz wrote: > On Tue, Jan 28, 2025 at 8:46=E2=80=AFAM Thomas Gleixner wrote: >> 1) Jiffies and related timer wheel interfaces >> >> jiffies should just go away completely and be replaced by a simple >> millisecond counter, which is accessible in the same way as >> jiffies today. >> >> That removes the bulk of HZ usage all over the place and makes the >> usage sites simpler as the interfaces just use SI units and the >> gazillions (~4500 to jiffies and ~1000 from jiffies) back and >> forth conversions just go away. > > Yeah, this was basically where I was hoping this would allow us to go. > I was imagining once dyn_hz was possible, we could basically fix HZ to > 1000 internally, leaving jiffies as that 1ms counter, and let the > actual interrupt rate be set via the dynhz default config value. Then > iterating through all the code switching HZ usage to MSEC_PER_SEC, etc > would be possible. I strongly suggest to start with exactly this because it significantly reduces the problem space and has a valuable benefit in general. >> 3) Accounting >> >> The accounting has to be seperated from the jiffies advancement and >> it has to feed the delta to the last tick in nanoseconds into the >> accounting path, which internally operates in nanoseconds already >> today. > > I'll take a look at this next, as the accounting has clearly been my > biggest fumbling point. Keeping the per-cpu last tick times is > probably the key change (my main concern is the extra cost of reading > the ns time, but deriving it from 1ms jiffies counter could be an > option), but yeah, I think this sounds like a nice direction. Thank > you for the suggestion! You don't need to read the time for that. The delta to the previous tick is known already. It's the amount of nanoseconds which corresponds to the chosen dynamic HZ value. So you can just do: - cputime =3D TICK_NSEC; + cputime =3D tick_nsec; i.e. read the variable which stores the tick length in nanoseconds, no? Thanks, tglx