linux-kernel - Re: [RFC][PATCH 0/3] DynamicHZ: Configuring the timer tick rate at boot time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87a5ba6nz5.ffs@tglx>
Date: Wed, 29 Jan 2025 09:09:02 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: John Stultz <jstultz@...gle.com>
Cc: LKML <linux-kernel@...r.kernel.org>, Anna-Maria Behnsen
 <anna-maria@...utronix.de>, Frederic Weisbecker <frederic@...nel.org>,
 Ingo Molnar <mingo@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
 Juri Lelli <juri.lelli@...hat.com>, Vincent Guittot
 <vincent.guittot@...aro.org>, Dietmar Eggemann <dietmar.eggemann@....com>,
 Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>, Mel
 Gorman <mgorman@...e.de>, Valentin Schneider <vschneid@...hat.com>,
 Stephen Boyd <sboyd@...nel.org>, Yury Norov <yury.norov@...il.com>, Bitao
 Hu <yaoma@...ux.alibaba.com>, Andrew Morton <akpm@...ux-foundation.org>,
 kernel-team@...roid.com, Saravana Kannan <saravanak@...gle.com>, Samuel Wu
 <wusamuel@...gle.com>, Qais Yousef <qyousef@...gle.com>
Subject: Re: [RFC][PATCH 0/3] DynamicHZ: Configuring the timer tick rate at
 boot time

On Tue, Jan 28 2025 at 22:10, John Stultz wrote:
> On Tue, Jan 28, 2025 at 8:46 AM Thomas Gleixner <tglx@...utronix.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.

>>   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 = TICK_NSEC;
+	cputime = tick_nsec;

i.e. read the variable which stores the tick length in nanoseconds, no?

Thanks,

        tglx