public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org,
	Frederic Weisbecker <frederic@kernel.org>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 00/17] timers: Complete the timer_*() API renames
Date: Wed, 16 Apr 2025 11:04:05 +0200	[thread overview]
Message-ID: <Z_9yhQg_jlbIkxHf@gmail.com> (raw)
In-Reply-To: <87ikn6sibi.ffs@tglx>


* Thomas Gleixner <tglx@linutronix.de> wrote:

> While I appreciate proper namespace prefixes, this series is just a
> mechanical conversion without any additional value.

Yes, intentionally so, as mentioned I didn't even rename any of the 
APIs beyond the trivial conversion, because I wanted to gather feedback 
first:

> > I didn't want to make bigger, discretionary changes in the first 
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > iteration, but I can easily propagate any such suggestions into 
    ^^^^^^^^^
> > future versions of this series.

    https://lore.kernel.org/all/Z_zk94RFo2bK85iJ@gmail.com/

Can you please acknowledge this clearly declared, intentionally limited 
scope of the -v1 series, instead of deriding it as 'mindless'? :-)

> [...] Some of the conversions like try_to_del_timer_sync() are 
> obviously fine and can't provide moar than a namespace consolidation.
> 
> But if you look at the actual functions and their usage all over the
> place then you can see that there is way more cleanup and consolidation
> potential especially for those functions which add or modify timers.
> 
> First of all the question is whether add() and mod() are really valuable
> distinctions. I'm not convinced at all. Back then, when we introduced
> hrtimers, we came to the conclusion that hrtimer_start() is sufficient.

I didn't want to mix namespace cleanups with functional cleanups, but 
sure, I'd be glad to do that too.

> But that aside there is a major cleanup potential for this stuff. The
> vast majority of add/mod_timer() sites uses:
> 
>     - Precomputed timeout values derived from a timeout provided in SE
>       units
> 
>     - Instant conversions of SE unit based timeouts to jiffies
> 
>           msec/usec/sec_to_jiffies()
> 
>     - All variants of HZ, HZ * N, HZ / N ....
> 
> This is lots of duplicated and copy and pasted code. So instead of
> blindly renaming things, we can be smarter and provide sensible
> functions:
> 
> mod_timer() takes an absolute expiry value, but most places use
> 
>     mod_timer(t, jiffies + $timeout);
> 
> So the obvious first step is to provide:
> 
>     timer_start_rel(t, $timeout);
> 
> which does the addition of jiffies under the hood.
> 
> And because $timeout is some of the above calculations, we can be
> smart and provide:
> 
>    timer_start_rel_secs(t, timeout_in_seconds);
>    timer_start_rel_msecs(t, timeout_in_milliseconds);
>    timer_start_rel_usecs(t, timeout_in_microseconds);
> 
> This all can be sensibly converted with coccinelle, which even can
> handle the cases where $timeout is calculated from HZ / N.
> 
> I have a pile of half finished coccinelle scripts somewhere, which do
> exactly such a conversion. I just ran out of time to play with that, as
> I ran into a few things which need more thoughts about proper
> interfaces. I'm happy to share them.

Please do!

See why I sent the simple approach first? :-)

> Converting the whole timer arming to use SE unit based timeouts makes 
> a lot of sense in general and also paves the way to boot-time 
> controlled HZ, which is something distros and others are asking for 
> since years (of course nobody wants to sit down and do the actual 
> work as usual...)
> 
> That said, I'm fine to convert the obvious things, like 
> try_timer_del*(), where there is no other consolidation value, but 
> for everything else we better sit down and think about proper 
> interfaces and large scale consolidation.

No arguments from me! :-)

Thanks,

	Ingo

      reply	other threads:[~2025-04-16  9:04 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-14 10:22 [PATCH 00/17] timers: Complete the timer_*() API renames Ingo Molnar
2025-04-14 10:22 ` [PATCH 01/17] rust: Rename timer_container_of() to hrtimer_container_of() Ingo Molnar
2025-04-14 10:22 ` [PATCH 02/17] scsi: bfa: Rename 'timer_mod' to 'timer_module' Ingo Molnar
2025-04-14 10:59   ` Thomas Weißschuh
2025-04-14 11:21     ` [PATCH -v2 " Ingo Molnar
2025-04-14 16:57   ` [PATCH " Linus Torvalds
2025-04-16  5:28     ` Ingo Molnar
2025-04-16  5:37       ` Ingo Molnar
2025-04-14 18:02   ` Thomas Gleixner
2025-04-16  5:32     ` Ingo Molnar
2025-04-16  5:39       ` Ingo Molnar
2025-04-15 17:50   ` David Laight
2025-04-14 10:22 ` [PATCH 03/17] treewide, timers: Rename add_timer_global() => timer_add_global() Ingo Molnar
2025-04-14 10:22 ` [PATCH 04/17] treewide, timers: Rename add_timer_local() => timer_add_local() Ingo Molnar
2025-04-14 10:22 ` [PATCH 05/17] treewide, timers: Rename from_timer() => timer_container_of() Ingo Molnar
2025-04-14 10:22 ` [PATCH 06/17] treewide, timers: Rename mod_timer_pending() => timer_mod_pending() Ingo Molnar
2025-04-14 10:22 ` [PATCH 07/17] treewide, timers: Rename try_to_del_timer_sync() => timer_delete_sync_try() Ingo Molnar
2025-04-14 10:22 ` [PATCH 08/17] treewide, timers: Rename add_timer() => timer_add() Ingo Molnar
2025-04-14 10:22 ` [PATCH 09/17] treewide, timers: Rename add_timer_on() => timer_add_on() Ingo Molnar
2025-04-14 10:22 ` [PATCH 10/17] treewide, timers: Rename mod_timer() => timer_mod() Ingo Molnar
2025-04-14 10:22 ` [PATCH 11/17] treewide, timers: Rename destroy_timer_on_stack() => timer_destroy_on_stack() Ingo Molnar
2025-04-14 10:22 ` [PATCH 12/17] treewide, timers: Rename init_timer_key() => timer_init_key() Ingo Molnar
2025-04-14 10:22 ` [PATCH 13/17] treewide, timers: Rename init_timer_on_stack_key() => timer_init_on_stack_key() Ingo Molnar
2025-04-14 10:22 ` [PATCH 14/17] treewide, timers: Rename __init_timer() => __timer_init() Ingo Molnar
2025-04-14 10:22 ` [PATCH 15/17] treewide, timers: Rename __init_timer_on_stack() => __timer_init_on_stack() Ingo Molnar
2025-04-14 10:22 ` [PATCH 16/17] treewide, timers: Rename NEXT_TIMER_MAX_DELTA => TIMER_NEXT_MAX_DELTA Ingo Molnar
2025-04-14 10:22 ` [PATCH 17/17] treewide, timers: Rename init_timers() => timers_init() Ingo Molnar
2025-04-14 10:35 ` [PATCH 00/17] timers: Complete the timer_*() API renames Ingo Molnar
2025-04-14 18:34   ` Thomas Gleixner
2025-04-16  9:04     ` Ingo Molnar [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z_9yhQg_jlbIkxHf@gmail.com \
    --to=mingo@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=frederic@kernel.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox