Messages in this thread |  | | Date | Mon, 10 Feb 2025 16:54:34 +0000 | | From | David Laight <> | | Subject | Re: [RFC][PATCH 0/3] DynamicHZ: Configuring the timer tick rate at boot time |
| |
On Wed, 29 Jan 2025 09:09:02 +0100 Thomas Gleixner <tglx@linutronix.de> wrote:
> On Tue, Jan 28 2025 at 22:10, John Stultz wrote: > > On Tue, Jan 28, 2025 at 8:46 AM Thomas Gleixner <tglx@linutronix.de> 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.
I doubt anyone will notice if a 250Hz timer interrupt always adds 4 to 'jiffies'.
One problem with increasing the frequency of the interrupt is the sheer amount of code that runs every timer tick. I suspect most of it is in the scheduler!
Do I recall that the timer wheels no longer move long timers onto the high resolution wheels? So longer timers are a much increased granularity. That is going to be made worse for anyone currently using a 250Hz 'tick'.
Making 'jiffies' milliseconds does stop you having a faster timer tick. I know one architecture kernel (might not have been Linux) defaulted to 1024Hz. But I'm not sure that is a problem.
32bit systems must be able to handle wrap - we all know (to our cost) that a 1ms counter wraps in 48 days. So even a 4ms one wraps quite often. Although having a 64bit (long) counter in 64bit mode really just hides bugs.
David
|  |