[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <877cx30xnt.ffs@tglx>
Date: Tue, 31 Jan 2023 12:08:06 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: shrikanth hegde <sshegde@...ux.vnet.ibm.com>
Cc: peterz@...radead.org, arjan@...ux.intel.com, mingo@...nel.org,
Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
svaidy@...ux.ibm.com, linux-kernel@...r.kernel.org,
bigeasy@...utronix.de
Subject: Re: [RFC PATCH] hrtimer: interleave timers for improved single
thread performance at low utilization
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
Powered by blists - more mailing lists