[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87k0qrtexe.fsf@nanos.tec.linutronix.de>
Date: Mon, 01 Mar 2021 10:13:17 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Mikael Beckius <mikael.beckius@...driver.com>,
anna-maria@...utronix.de
Cc: linux-kernel@...r.kernel.org, mikael.beckius@...driver.com
Subject: Re: Sv: Sv: [PATCH] hrtimer: Interrupt storm on clock_settime
Micke,
On Thu, Feb 25 2021 at 12:18, Mikael Beckius wrote:
>> The proposed change breaks the reprogramming logic. To keep it working
>> cpu_base::*expires_next is only updated by hrtimer_reprogram() and
>> hrtimer_interrupt(). I will send you a patch for testing in reply to this
>> thread. The patch is compile tested only.
>>
> Ok. I kind of guessed that would be the response as I noticed a similar comment
> during the review of the original patch which introduced the softirq_expires_next
> logic. Anyway it seemed logical to update softirq_expires_next
> when updating softirq_next_timer.
yes it seems logical to do that, but unfortunately the logic there is a
bit twisted and could do with some deobfuscation.
Thanks,
tglx
Powered by blists - more mailing lists