All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.