Re: [RFC GIT PULL] timer subsystem fix/improvement

[Linus Torvalds]

On Sun, 1 Mar 2026 at 01:18, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
> (Marked as an RFC pull request, as it's not a regression.)

Bah, I'm going to pull this as ObviouslyCorrect(tm), but I think it
could have been done much simpler and better without repeating the
detailed "use inline for this case" or having any extra logic.

We have a good and very intuitive pattern for "this function has been
defined already": just define the name. Not *another* name. Not some
complicated expression that might change in the future. Just the exact
name of the function.

And that works fine for inline functions (just also do a #define to
itself in addition to the function), but it works _particularly_ well
for the trivial cases when you don't even need a function at all, and
can just use a #define directly.

Like in this case.

IOW, this could all have done something really simple like

  unsigned int jiffies_to_msecs(const unsigned long j);

  // The common case of HZ in {100,250,1000} is trivial
  #if !(MSEC_PER_SEC % HZ)
    #define jiffies_to_msecs(j) (unsigned int)((MSEC_PER_SEC / HZ) * (j)
  #endif

(the "HZ <= MSEC_PER_SEC" test in that patch is unnecessary: if HZ is
larger than  MSEC_PER_SEC, then that modulus will just be
MSEC_PER_SEC, which isn't zero!)

And then in kernel/time/time.c you just do that standard "do I already
have this" pattern:

   #ifndef jiffies_to_msecs
   ...
  #endif

around the out-of-line version.

No duplicate expressions for the condition of inlining. No artificial
new configuration symbols. Not even any #else conditionals (well, they
are needed if you *really* want an actual inline function, but for "we
have a function declaration and then we have a simpler case using a
macro" it's actually easier to just let the function declaration be
unconditional and just do the macro definition afterwards - C is a
one-pass language when it comes to parsing).

And that

    BUILD_BUG_ON(HZ > USEC_PER_SEC);

shouldn't be in a header file or inside a function. It should have been just a

   static_assert(HZ <= USEC_PER_SEC);

in the timer code somewhere. If it's needed at all - I think people
would figure it out pretty quickly if they changed HZ to a value that
didn't work, there seems little advantage to "future-proofing" for a
case that is trivial.

IOW, it all just seems unnecessarily complicated, but I'm not going to
bother to rewrite it - I'm just writing a long "look, *next* time,
please just do the simple and straightforward thing" email instead.

              Linus