Re: [PATCH] hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event()
From: Thomas Gleixner
Date: Tue Apr 20 2021 - 02:44:56 EST
On Mon, Apr 19 2021 at 20:12, Maciej Żenczykowski wrote:
> On Thu, Apr 15, 2021 at 9:47 AM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
>> Run the test on a kernels with and without that commit and collect trace
>> data for both.
>> That should give me a pretty clear picture what's going on.
> Lorenzo is trying to get the traces you asked for, or rather he’s
> trying to get confirmation he can post them.
> Our initial observation of these results seems to suggest that
> updating the timer (hrtimer_start, which seems to also call
> hrtimer_cancel) takes twice as long as it used to.
Which contradicts my measurements. The change in complexity is marginal
and the overhead in cycles/instructions is close to noise. It's
measurable in a microbenchmark, but it's in the < 1% range which is far
away from the 60% you are seing.
> My gut feeling is that softirq_activated is usually false, and the old
> code in such a case calls just __hrtimer_get_next_event(,
> HRTIMER_ACTIVE_ALL). While the new code will first call
> __hrtimer_get_next_event(, HRTIMER_ACTIVE_SOFT) and then
> __hrtimer_get_next_event(, HRTIMER_ACTIVE_HARD)
> Perhaps __hrtimer_get_next_event() should return both soft and hard
> event times in one function call?
> Or perhaps hrtimer_start should not call hrtimer_cancel?
Perhaps we do a proper analysis first :)