Re: [RFC PATCH] hrtimer: interleave timers for improved single thread performance at low utilization

[Thomas Gleixner <tglx@linutronix.de>]

On Tue, Jan 31 2023 at 11:18, shrikanth hegde wrote:
> As per current design of hrtimer, it uses the _softexpires to trigger the
> timer function.  _softexpires is set as multiple of the period/interval value.

Wrong. _softexpires is _hardexpires + slack. The slack allows for
batching which:

> This will benefit the power saving by less wakeups.

But that has absolutely nothing to do with your problem:

> Due to this, different timers of the same period/interval values align
> and the callbacks functions will be called at the same time.

The whole point of hrtimer_forward_now() is to forward the expiry time
of a timer with the given period so that it expires after 'now'.

That's functionality which is used by a lot of callers to implement
proper periodic timers.

> Came up with a naive patch, more of hack.

A broken hack to be precise because any existing user of
hrtimer_forward() will be broken by this hack.

> Other alternative is to use a slightly modified API for cgroups, so
> that all other timers align and wakeups remain reduced.

I'm not seeing why you need a new API for that. The problem is _NOT_ in
the hrtimer code at all.

Lets look at the math:

    expiry = $INITIAL_EXPIRYVALUE + $N * $PERIOD

If $INITIAL_EXPIRYVALUE is the same then for all instances then
obviously the expiry values of all instances will be all aligned on
multiples of $PERIOD, right?

So why the heck do you need a new hrtimer API? There is an obvious
solution, right?

Thanks,

        tglx