Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [RFC PATCH] hrtimer: interleave timers for improved single thread performance at low utilization | Date | Tue, 31 Jan 2023 12:08:06 +0100 |
| |
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
| |