public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [RFC GIT PULL] timer subsystem fix/improvement
@ 2026-03-01  9:18 Ingo Molnar
  2026-03-01 19:49 ` Linus Torvalds
  0 siblings, 1 reply; 2+ messages in thread
From: Ingo Molnar @ 2026-03-01  9:18 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: linux-kernel, Thomas Gleixner, Daniel Lezcano, Peter Zijlstra,
	Anna-Maria Behnsen, Frederic Weisbecker

Linus,

Please pull the latest timers/urgent Git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-urgent-2026-03-01

for you to fetch changes up to b777b5e09eabeefc6ba80f4296366a4742701103:

# MERGE NOTE: marked as RFC, as it's not a regression fix.

Improve the inlining of jiffies_to_msecs() and jiffies_to_usecs(),
for the common HZ=100, 250 or 1000 cases, only inlining them
for odd HZ values like HZ=300.

The inlining overhead showed up in performance tests of the TCP code.

(Marked as an RFC pull request, as it's not a regression.)

 Thanks,

	Ingo

------------------>
Eric Dumazet (1):
      time/jiffies: Inline jiffies_to_msecs() and jiffies_to_usecs()


 include/linux/jiffies.h | 40 ++++++++++++++++++++++++++++++++++++++--
 kernel/time/time.c      | 19 +++++++------------
 2 files changed, 45 insertions(+), 14 deletions(-)

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [RFC GIT PULL] timer subsystem fix/improvement
  2026-03-01  9:18 [RFC GIT PULL] timer subsystem fix/improvement Ingo Molnar
@ 2026-03-01 19:49 ` Linus Torvalds
  0 siblings, 0 replies; 2+ messages in thread
From: Linus Torvalds @ 2026-03-01 19:49 UTC (permalink / raw)
  To: Ingo Molnar, Eric Dumazet
  Cc: linux-kernel, Thomas Gleixner, Daniel Lezcano, Peter Zijlstra,
	Anna-Maria Behnsen, Frederic Weisbecker

On Sun, 1 Mar 2026 at 01:18, Ingo Molnar <mingo@kernel.org> 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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-03-01 19:50 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-03-01  9:18 [RFC GIT PULL] timer subsystem fix/improvement Ingo Molnar
2026-03-01 19:49 ` Linus Torvalds

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox