* [PATCH] hrtimer: Interrupt storm on clock_settime @ 2021-01-28 14:02 Mikael Beckius 2021-02-05 15:45 ` Thomas Gleixner 2021-02-09 15:22 ` [tip: timers/urgent] hrtimer: Update softirq_expires_next correctly in hrtimer_force_reprogram() tip-bot2 for Mikael Beckius 0 siblings, 2 replies; 12+ messages in thread From: Mikael Beckius @ 2021-01-28 14:02 UTC (permalink / raw) To: linux-kernel, tglx During clock_settime absolute realtime timers may get updated to expire sooner in absolute monotonic time but if hrtimer_force_reprogram is called as part of a clock_settime and the next hard hrtimer expires before the next soft hrtimer softirq_expires_next will not be updated to reflect this change (assuming the realtime timer is a soft timer). This means that if the next soft hrtimer expires before softirq_expires_next but after now no soft hrtimer interrupt will be raised in hrtimer_interrupt which will instead retry tick_program_event three times before forcing a tick_program_event using a very short delay entering hrtimer_interrupt again almost immediately repeating the process over and over again until now exceeds softirq_expires_next and a soft hrtimer interrupt is finally raised. This patch aims to solve this by always updating softirq_expires_next if a soft hrtimer exists. Signed-off-by: Mikael Beckius <mikael.beckius@windriver.com> --- kernel/time/hrtimer.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index 743c852e10f2..e4c233f404b1 100644 --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -633,7 +633,7 @@ hrtimer_force_reprogram(struct hrtimer_cpu_base *cpu_base, int skip_equal) */ expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL); - if (cpu_base->next_timer && cpu_base->next_timer->is_soft) { + if (cpu_base->softirq_next_timer) { /* * When the softirq is activated, hrtimer has to be * programmed with the first hard hrtimer because soft @@ -643,7 +643,8 @@ hrtimer_force_reprogram(struct hrtimer_cpu_base *cpu_base, int skip_equal) expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_HARD); else - cpu_base->softirq_expires_next = expires_next; + cpu_base->softirq_expires_next = __hrtimer_get_next_event(cpu_base, + HRTIMER_ACTIVE_SOFT); } if (skip_equal && expires_next == cpu_base->expires_next) -- 2.28.0 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] hrtimer: Interrupt storm on clock_settime 2021-01-28 14:02 [PATCH] hrtimer: Interrupt storm on clock_settime Mikael Beckius @ 2021-02-05 15:45 ` Thomas Gleixner 2021-02-12 13:38 ` Sv: " Beckius, Mikael 2021-02-09 15:22 ` [tip: timers/urgent] hrtimer: Update softirq_expires_next correctly in hrtimer_force_reprogram() tip-bot2 for Mikael Beckius 1 sibling, 1 reply; 12+ messages in thread From: Thomas Gleixner @ 2021-02-05 15:45 UTC (permalink / raw) To: Mikael Beckius, linux-kernel; +Cc: Anna-Maria Behnsen On Thu, Jan 28 2021 at 15:02, Mikael Beckius wrote: > During clock_settime absolute realtime timers may get updated to expire > sooner in absolute monotonic time but if hrtimer_force_reprogram is > called as part of a clock_settime and the next hard hrtimer expires > before the next soft hrtimer softirq_expires_next will not be updated > to reflect this change (assuming the realtime timer is a soft timer). > > This means that if the next soft hrtimer expires before > softirq_expires_next but after now no soft hrtimer interrupt will be > raised in hrtimer_interrupt which will instead retry tick_program_event > three times before forcing a tick_program_event using a very short delay > entering hrtimer_interrupt again almost immediately repeating the > process over and over again until now exceeds softirq_expires_next and a > soft hrtimer interrupt is finally raised. Duh. > This patch aims to solve this by always updating softirq_expires_next if > a soft hrtimer exists. git grep 'This patch' Documentation/process/ > Signed-off-by: Mikael Beckius <mikael.beckius@windriver.com> > --- > kernel/time/hrtimer.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c > index 743c852e10f2..e4c233f404b1 100644 > --- a/kernel/time/hrtimer.c > +++ b/kernel/time/hrtimer.c > @@ -633,7 +633,7 @@ hrtimer_force_reprogram(struct hrtimer_cpu_base *cpu_base, int skip_equal) > */ > expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL); > > - if (cpu_base->next_timer && cpu_base->next_timer->is_soft) { > + if (cpu_base->softirq_next_timer) { > /* > * When the softirq is activated, hrtimer has to be > * programmed with the first hard hrtimer because soft > @@ -643,7 +643,8 @@ hrtimer_force_reprogram(struct hrtimer_cpu_base *cpu_base, int skip_equal) > expires_next = __hrtimer_get_next_event(cpu_base, > HRTIMER_ACTIVE_HARD); > else > - cpu_base->softirq_expires_next = expires_next; > + cpu_base->softirq_expires_next = __hrtimer_get_next_event(cpu_base, > + HRTIMER_ACTIVE_SOFT); That works, but we can spare the double scan completely and make the code understandable. See below. Thanks, tglx --- --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -626,26 +626,25 @@ static inline int hrtimer_hres_active(vo static void hrtimer_force_reprogram(struct hrtimer_cpu_base *cpu_base, int skip_equal) { - ktime_t expires_next; + ktime_t expires_next, soft = KTIME_MAX; /* - * Find the current next expiration time. + * If soft interrupt has already been activated, ignore the soft + * base. It will be handled in the already raised soft interrupt. */ - expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL); - - if (cpu_base->next_timer && cpu_base->next_timer->is_soft) { + if (!cpu_base->softirq_activated) { + soft = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_SOFT); /* - * When the softirq is activated, hrtimer has to be - * programmed with the first hard hrtimer because soft - * timer interrupt could occur too late. + * Update the soft expiry time. clock_settime() might have + * affected it. */ - if (cpu_base->softirq_activated) - expires_next = __hrtimer_get_next_event(cpu_base, - HRTIMER_ACTIVE_HARD); - else - cpu_base->softirq_expires_next = expires_next; + cpu_base->softirq_expires_next = soft; } + expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_HARD); + if (expires_next > soft) + expires_next = soft; + if (skip_equal && expires_next == cpu_base->expires_next) return; ^ permalink raw reply [flat|nested] 12+ messages in thread
* Sv: [PATCH] hrtimer: Interrupt storm on clock_settime 2021-02-05 15:45 ` Thomas Gleixner @ 2021-02-12 13:38 ` Beckius, Mikael 2021-02-23 15:53 ` Anna-Maria Behnsen 2021-02-23 16:02 ` [PATCH] hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() Anna-Maria Behnsen 0 siblings, 2 replies; 12+ messages in thread From: Beckius, Mikael @ 2021-02-12 13:38 UTC (permalink / raw) To: Thomas Gleixner, linux-kernel; +Cc: Anna-Maria Behnsen Thanks for the update and sorry for the late reply. After long-term testing of the patch, storm detection improved, it turns out that a similar problem can occur if hrtimer_interrupt runs during clock_settime. In this case it seems the offset can get updated and later read using hrtimer_update_base in hrtimer_interrupt before softirq_expires_next gets updated. As soon as softirq_expires_next gets updated by hrtimer_force_reprogram the storm ends. To fix this I made the below changes. --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -529,8 +529,10 @@ static ktime_t __hrtimer_next_event_base(struct hrtimer_cpu_base *cpu_base, if (exclude) continue; - if (timer->is_soft) + if (timer->is_soft) { cpu_base->softirq_next_timer = timer; + cpu_base->softirq_expires_next = expires; + } else cpu_base->next_timer = timer; } @@ -633,19 +635,6 @@ hrtimer_force_reprogram(struct hrtimer_cpu_base *cpu_base, int skip_equal) */ expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL); - if (cpu_base->next_timer && cpu_base->next_timer->is_soft) { - /* - * When the softirq is activated, hrtimer has to be - * programmed with the first hard hrtimer because soft - * timer interrupt could occur too late. - */ - if (cpu_base->softirq_activated) - expires_next = __hrtimer_get_next_event(cpu_base, - HRTIMER_ACTIVE_HARD); - else - cpu_base->softirq_expires_next = expires_next; - } - if (skip_equal && expires_next == cpu_base->expires_next) return; -- This is similar to hrtimer_reprogram. I also removed the cpu_base->softirq_activated case since as far as I can tell expires_next must be hard if cpu_base->softirq_activated is true. I might be missing something as I don't have whole picture of the hrtimer subsystem but at least no interrupt storms are detected during clock_settime with latest changes. Micke ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Sv: [PATCH] hrtimer: Interrupt storm on clock_settime 2021-02-12 13:38 ` Sv: " Beckius, Mikael @ 2021-02-23 15:53 ` Anna-Maria Behnsen 2021-02-25 11:18 ` Sv: " Mikael Beckius 2021-02-23 16:02 ` [PATCH] hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() Anna-Maria Behnsen 1 sibling, 1 reply; 12+ messages in thread From: Anna-Maria Behnsen @ 2021-02-23 15:53 UTC (permalink / raw) To: Beckius, Mikael; +Cc: Thomas Gleixner, linux-kernel Hi Micke, On Fri, 12 Feb 2021, Beckius, Mikael wrote: > Thanks for the update and sorry for the late reply. After long-term > testing of the patch, storm detection improved, it turns out that a > similar problem can occur if hrtimer_interrupt runs during > clock_settime. In this case it seems the offset can get updated and later > read using hrtimer_update_base in hrtimer_interrupt before > softirq_expires_next gets updated. As soon as softirq_expires_next gets > updated by hrtimer_force_reprogram the storm ends. To fix this I made the > below changes. > > --- a/kernel/time/hrtimer.c > +++ b/kernel/time/hrtimer.c > @@ -529,8 +529,10 @@ static ktime_t __hrtimer_next_event_base(struct hrtimer_cpu_base *cpu_base, > if (exclude) > continue; > > - if (timer->is_soft) > + if (timer->is_soft) { > cpu_base->softirq_next_timer = timer; > + cpu_base->softirq_expires_next = expires; > + } > else > cpu_base->next_timer = timer; > } > @@ -633,19 +635,6 @@ hrtimer_force_reprogram(struct hrtimer_cpu_base *cpu_base, int skip_equal) > */ > expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL); > > - if (cpu_base->next_timer && cpu_base->next_timer->is_soft) { > - /* > - * When the softirq is activated, hrtimer has to be > - * programmed with the first hard hrtimer because soft > - * timer interrupt could occur too late. > - */ > - if (cpu_base->softirq_activated) > - expires_next = __hrtimer_get_next_event(cpu_base, > - HRTIMER_ACTIVE_HARD); > - else > - cpu_base->softirq_expires_next = expires_next; > - } > - > if (skip_equal && expires_next == cpu_base->expires_next) > return; > > -- > 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. Thanks, Anna-Maria ^ permalink raw reply [flat|nested] 12+ messages in thread
* Sv: Sv: [PATCH] hrtimer: Interrupt storm on clock_settime 2021-02-23 15:53 ` Anna-Maria Behnsen @ 2021-02-25 11:18 ` Mikael Beckius 2021-03-01 9:13 ` Thomas Gleixner 0 siblings, 1 reply; 12+ messages in thread From: Mikael Beckius @ 2021-02-25 11:18 UTC (permalink / raw) To: anna-maria; +Cc: linux-kernel, mikael.beckius, tglx > 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. Micke ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Sv: Sv: [PATCH] hrtimer: Interrupt storm on clock_settime 2021-02-25 11:18 ` Sv: " Mikael Beckius @ 2021-03-01 9:13 ` Thomas Gleixner 0 siblings, 0 replies; 12+ messages in thread From: Thomas Gleixner @ 2021-03-01 9:13 UTC (permalink / raw) To: Mikael Beckius, anna-maria; +Cc: linux-kernel, mikael.beckius 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() 2021-02-12 13:38 ` Sv: " Beckius, Mikael 2021-02-23 15:53 ` Anna-Maria Behnsen @ 2021-02-23 16:02 ` Anna-Maria Behnsen 2021-02-25 11:18 ` Sv: " Mikael Beckius ` (3 more replies) 1 sibling, 4 replies; 12+ messages in thread From: Anna-Maria Behnsen @ 2021-02-23 16:02 UTC (permalink / raw) To: mikael.beckius; +Cc: tglx, linux-kernel hrtimer_force_reprogram() and hrtimer_interrupt() invokes __hrtimer_get_next_event() to find the earliest expiry time of hrtimer bases. __hrtimer_get_next_event() does not update cpu_base::[softirq_]_expires_next to preserve reprogramming logic. That needs to be done at the callsites. hrtimer_force_reprogram() updates cpu_base::softirq_expires_next only when the first expiring timer is a softirq timer and the soft interrupt is not activated. That's wrong because cpu_base::softirq_expires_next is left stale when the first expiring timer of all bases is a timer which expires in hard interrupt context. hrtimer_interrupt() does never update cpu_base::softirq_expires_next which is wrong too. That becomes a problem when clock_settime() sets CLOCK_REALTIME forward and the first soft expiring timer is in the CLOCK_REALTIME_SOFT base. Setting CLOCK_REALTIME forward moves the clock MONOTONIC based expiry time of that timer before the stale cpu_base::softirq_expires_next. cpu_base::softirq_expires_next is cached to make the check for raising the soft interrupt fast. In the above case the soft interrupt won't be raised until clock monotonic reaches the stale cpu_base::softirq_expires_next value. That's incorrect, but what's worse it that if the softirq timer becomes the first expiring timer of all clock bases after the hard expiry timer has been handled the reprogramming of the clockevent from hrtimer_interrupt() will result in an interrupt storm. That happens because the reprogramming does not use cpu_base::softirq_expires_next, it uses __hrtimer_get_next_event() which returns the actual expiry time. Once clock MONOTONIC reaches cpu_base::softirq_expires_next the soft interrupt is raised and the storm subsides. Change the logic in hrtimer_force_reprogram() to evaluate the soft and hard bases seperately, update softirq_expires_next and handle the case when a soft expiring timer is the first of all bases by comparing the expiry times and updating the required cpu base fields. Split this functionality into a separate function to be able to use it in hrtimer_interrupt() as well without copy paste. Micke, please test this patch - it is compile tested only... Fixes:5da70160462e ("hrtimer: Implement support for softirq based hrtimers") Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Reported-by: Mikael Beckius <mikael.beckius@windriver.com> --- kernel/time/hrtimer.c | 53 +++++++++++++++++++++++++++---------------- 1 file changed, 34 insertions(+), 19 deletions(-) diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index 46bd35d5fc0d..788b9d137de4 100644 --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -591,6 +591,37 @@ __hrtimer_get_next_event(struct hrtimer_cpu_base *cpu_base, unsigned int active_ return expires_next; } +static ktime_t hrtimer_update_next_event(struct hrtimer_cpu_base *cpu_base) +{ + ktime_t expires_next, soft = KTIME_MAX; + + /* + * If the soft interrupt has already been activated, ignore the + * soft bases. They will be handled in the already raised soft + * interrupt. + */ + if (!cpu_base->softirq_activated) { + soft = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_SOFT); + /* + * Update the soft expiry time. clock_settime() might have + * affected it. + */ + cpu_base->softirq_expires_next = soft; + } + + expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_HARD); + /* + * If a softirq timer is expiring first, update cpu_base->next_timer + * and program the hardware with the soft expiry time. + */ + if (expires_next > soft) { + cpu_base->next_timer = cpu_base->softirq_next_timer; + expires_next = soft; + } + + return expires_next; +} + static inline ktime_t hrtimer_update_base(struct hrtimer_cpu_base *base) { ktime_t *offs_real = &base->clock_base[HRTIMER_BASE_REALTIME].offset; @@ -631,23 +662,7 @@ hrtimer_force_reprogram(struct hrtimer_cpu_base *cpu_base, int skip_equal) { ktime_t expires_next; - /* - * Find the current next expiration time. - */ - expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL); - - if (cpu_base->next_timer && cpu_base->next_timer->is_soft) { - /* - * When the softirq is activated, hrtimer has to be - * programmed with the first hard hrtimer because soft - * timer interrupt could occur too late. - */ - if (cpu_base->softirq_activated) - expires_next = __hrtimer_get_next_event(cpu_base, - HRTIMER_ACTIVE_HARD); - else - cpu_base->softirq_expires_next = expires_next; - } + expires_next = hrtimer_update_next_event(cpu_base); if (skip_equal && expires_next == cpu_base->expires_next) return; @@ -1647,8 +1662,8 @@ void hrtimer_interrupt(struct clock_event_device *dev) __hrtimer_run_queues(cpu_base, now, flags, HRTIMER_ACTIVE_HARD); - /* Reevaluate the clock bases for the next expiry */ - expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL); + /* Reevaluate the clock bases for the [soft] next expiry */ + expires_next = hrtimer_update_next_event(cpu_base); /* * Store the new expiry value so the migration code can verify * against it. -- 2.20.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Sv: [PATCH] hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() 2021-02-23 16:02 ` [PATCH] hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() Anna-Maria Behnsen @ 2021-02-25 11:18 ` Mikael Beckius 2021-03-01 9:23 ` [tip: timers/urgent] " tip-bot2 for Anna-Maria Behnsen ` (2 subsequent siblings) 3 siblings, 0 replies; 12+ messages in thread From: Mikael Beckius @ 2021-02-25 11:18 UTC (permalink / raw) To: anna-maria; +Cc: linux-kernel, mikael.beckius, tglx > Micke, please test this patch - it is compile tested only... Thanks Anna-Maria, it seems to work equally good or better than the change I suggested in preventing interrupt storms. After running a test I created, based on traces from a live system, several thousands of iterations there are no reproductions. Normally both issues will reproduce within seconds after only a few iterations. Also by looking at the source code it seems like your patch should do the trick. Micke ^ permalink raw reply [flat|nested] 12+ messages in thread
* [tip: timers/urgent] hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() 2021-02-23 16:02 ` [PATCH] hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() Anna-Maria Behnsen 2021-02-25 11:18 ` Sv: " Mikael Beckius @ 2021-03-01 9:23 ` tip-bot2 for Anna-Maria Behnsen 2021-03-06 12:00 ` tip-bot2 for Anna-Maria Behnsen 2021-03-08 8:41 ` tip-bot2 for Anna-Maria Behnsen 3 siblings, 0 replies; 12+ messages in thread From: tip-bot2 for Anna-Maria Behnsen @ 2021-03-01 9:23 UTC (permalink / raw) To: linux-tip-commits Cc: Mikael Beckius, Thomas Gleixner, Anna-Maria Behnsen, x86, linux-kernel The following commit has been merged into the timers/urgent branch of tip: Commit-ID: 05f7fcc675f50001a30b8938c05d11ca9f599f8c Gitweb: https://git.kernel.org/tip/05f7fcc675f50001a30b8938c05d11ca9f599f8c Author: Anna-Maria Behnsen <anna-maria@linutronix.de> AuthorDate: Tue, 23 Feb 2021 17:02:40 +01:00 Committer: Thomas Gleixner <tglx@linutronix.de> CommitterDate: Mon, 01 Mar 2021 10:17:56 +01:00 hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() hrtimer_force_reprogram() and hrtimer_interrupt() invokes __hrtimer_get_next_event() to find the earliest expiry time of hrtimer bases. __hrtimer_get_next_event() does not update cpu_base::[softirq_]_expires_next to preserve reprogramming logic. That needs to be done at the callsites. hrtimer_force_reprogram() updates cpu_base::softirq_expires_next only when the first expiring timer is a softirq timer and the soft interrupt is not activated. That's wrong because cpu_base::softirq_expires_next is left stale when the first expiring timer of all bases is a timer which expires in hard interrupt context. hrtimer_interrupt() does never update cpu_base::softirq_expires_next which is wrong too. That becomes a problem when clock_settime() sets CLOCK_REALTIME forward and the first soft expiring timer is in the CLOCK_REALTIME_SOFT base. Setting CLOCK_REALTIME forward moves the clock MONOTONIC based expiry time of that timer before the stale cpu_base::softirq_expires_next. cpu_base::softirq_expires_next is cached to make the check for raising the soft interrupt fast. In the above case the soft interrupt won't be raised until clock monotonic reaches the stale cpu_base::softirq_expires_next value. That's incorrect, but what's worse it that if the softirq timer becomes the first expiring timer of all clock bases after the hard expiry timer has been handled the reprogramming of the clockevent from hrtimer_interrupt() will result in an interrupt storm. That happens because the reprogramming does not use cpu_base::softirq_expires_next, it uses __hrtimer_get_next_event() which returns the actual expiry time. Once clock MONOTONIC reaches cpu_base::softirq_expires_next the soft interrupt is raised and the storm subsides. Change the logic in hrtimer_force_reprogram() to evaluate the soft and hard bases seperately, update softirq_expires_next and handle the case when a soft expiring timer is the first of all bases by comparing the expiry times and updating the required cpu base fields. Split this functionality into a separate function to be able to use it in hrtimer_interrupt() as well without copy paste. Fixes: da70160462e ("hrtimer: Implement support for softirq based hrtimers") Reported-by: Mikael Beckius <mikael.beckius@windriver.com> Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Tested-by: Mikael Beckius <mikael.beckius@windriver.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20210223160240.27518-1-anna-maria@linutronix.de --- kernel/time/hrtimer.c | 60 +++++++++++++++++++++++++++--------------- 1 file changed, 39 insertions(+), 21 deletions(-) diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index 743c852..788b9d1 100644 --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -546,8 +546,11 @@ static ktime_t __hrtimer_next_event_base(struct hrtimer_cpu_base *cpu_base, } /* - * Recomputes cpu_base::*next_timer and returns the earliest expires_next but - * does not set cpu_base::*expires_next, that is done by hrtimer_reprogram. + * Recomputes cpu_base::*next_timer and returns the earliest expires_next + * but does not set cpu_base::*expires_next, that is done by + * hrtimer[_force]_reprogram and hrtimer_interrupt only. When updating + * cpu_base::*expires_next right away, reprogramming logic would no longer + * work. * * When a softirq is pending, we can ignore the HRTIMER_ACTIVE_SOFT bases, * those timers will get run whenever the softirq gets handled, at the end of @@ -588,6 +591,37 @@ __hrtimer_get_next_event(struct hrtimer_cpu_base *cpu_base, unsigned int active_ return expires_next; } +static ktime_t hrtimer_update_next_event(struct hrtimer_cpu_base *cpu_base) +{ + ktime_t expires_next, soft = KTIME_MAX; + + /* + * If the soft interrupt has already been activated, ignore the + * soft bases. They will be handled in the already raised soft + * interrupt. + */ + if (!cpu_base->softirq_activated) { + soft = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_SOFT); + /* + * Update the soft expiry time. clock_settime() might have + * affected it. + */ + cpu_base->softirq_expires_next = soft; + } + + expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_HARD); + /* + * If a softirq timer is expiring first, update cpu_base->next_timer + * and program the hardware with the soft expiry time. + */ + if (expires_next > soft) { + cpu_base->next_timer = cpu_base->softirq_next_timer; + expires_next = soft; + } + + return expires_next; +} + static inline ktime_t hrtimer_update_base(struct hrtimer_cpu_base *base) { ktime_t *offs_real = &base->clock_base[HRTIMER_BASE_REALTIME].offset; @@ -628,23 +662,7 @@ hrtimer_force_reprogram(struct hrtimer_cpu_base *cpu_base, int skip_equal) { ktime_t expires_next; - /* - * Find the current next expiration time. - */ - expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL); - - if (cpu_base->next_timer && cpu_base->next_timer->is_soft) { - /* - * When the softirq is activated, hrtimer has to be - * programmed with the first hard hrtimer because soft - * timer interrupt could occur too late. - */ - if (cpu_base->softirq_activated) - expires_next = __hrtimer_get_next_event(cpu_base, - HRTIMER_ACTIVE_HARD); - else - cpu_base->softirq_expires_next = expires_next; - } + expires_next = hrtimer_update_next_event(cpu_base); if (skip_equal && expires_next == cpu_base->expires_next) return; @@ -1644,8 +1662,8 @@ retry: __hrtimer_run_queues(cpu_base, now, flags, HRTIMER_ACTIVE_HARD); - /* Reevaluate the clock bases for the next expiry */ - expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL); + /* Reevaluate the clock bases for the [soft] next expiry */ + expires_next = hrtimer_update_next_event(cpu_base); /* * Store the new expiry value so the migration code can verify * against it. ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [tip: timers/urgent] hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() 2021-02-23 16:02 ` [PATCH] hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() Anna-Maria Behnsen 2021-02-25 11:18 ` Sv: " Mikael Beckius 2021-03-01 9:23 ` [tip: timers/urgent] " tip-bot2 for Anna-Maria Behnsen @ 2021-03-06 12:00 ` tip-bot2 for Anna-Maria Behnsen 2021-03-08 8:41 ` tip-bot2 for Anna-Maria Behnsen 3 siblings, 0 replies; 12+ messages in thread From: tip-bot2 for Anna-Maria Behnsen @ 2021-03-06 12:00 UTC (permalink / raw) To: linux-tip-commits Cc: Mikael Beckius, Thomas Gleixner, Anna-Maria Behnsen, Ingo Molnar, x86, linux-kernel The following commit has been merged into the timers/urgent branch of tip: Commit-ID: eca8f0c80a005aea84df507a446fc0154fc55a32 Gitweb: https://git.kernel.org/tip/eca8f0c80a005aea84df507a446fc0154fc55a32 Author: Anna-Maria Behnsen <anna-maria@linutronix.de> AuthorDate: Tue, 23 Feb 2021 17:02:40 +01:00 Committer: Ingo Molnar <mingo@kernel.org> CommitterDate: Sat, 06 Mar 2021 12:53:47 +01:00 hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() hrtimer_force_reprogram() and hrtimer_interrupt() invokes __hrtimer_get_next_event() to find the earliest expiry time of hrtimer bases. __hrtimer_get_next_event() does not update cpu_base::[softirq_]_expires_next to preserve reprogramming logic. That needs to be done at the callsites. hrtimer_force_reprogram() updates cpu_base::softirq_expires_next only when the first expiring timer is a softirq timer and the soft interrupt is not activated. That's wrong because cpu_base::softirq_expires_next is left stale when the first expiring timer of all bases is a timer which expires in hard interrupt context. hrtimer_interrupt() does never update cpu_base::softirq_expires_next which is wrong too. That becomes a problem when clock_settime() sets CLOCK_REALTIME forward and the first soft expiring timer is in the CLOCK_REALTIME_SOFT base. Setting CLOCK_REALTIME forward moves the clock MONOTONIC based expiry time of that timer before the stale cpu_base::softirq_expires_next. cpu_base::softirq_expires_next is cached to make the check for raising the soft interrupt fast. In the above case the soft interrupt won't be raised until clock monotonic reaches the stale cpu_base::softirq_expires_next value. That's incorrect, but what's worse it that if the softirq timer becomes the first expiring timer of all clock bases after the hard expiry timer has been handled the reprogramming of the clockevent from hrtimer_interrupt() will result in an interrupt storm. That happens because the reprogramming does not use cpu_base::softirq_expires_next, it uses __hrtimer_get_next_event() which returns the actual expiry time. Once clock MONOTONIC reaches cpu_base::softirq_expires_next the soft interrupt is raised and the storm subsides. Change the logic in hrtimer_force_reprogram() to evaluate the soft and hard bases seperately, update softirq_expires_next and handle the case when a soft expiring timer is the first of all bases by comparing the expiry times and updating the required cpu base fields. Split this functionality into a separate function to be able to use it in hrtimer_interrupt() as well without copy paste. Fixes: da70160462e ("hrtimer: Implement support for softirq based hrtimers") Reported-by: Mikael Beckius <mikael.beckius@windriver.com> Suggested-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Mikael Beckius <mikael.beckius@windriver.com> Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20210223160240.27518-1-anna-maria@linutronix.de --- kernel/time/hrtimer.c | 60 +++++++++++++++++++++++++++--------------- 1 file changed, 39 insertions(+), 21 deletions(-) diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index 743c852..788b9d1 100644 --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -546,8 +546,11 @@ static ktime_t __hrtimer_next_event_base(struct hrtimer_cpu_base *cpu_base, } /* - * Recomputes cpu_base::*next_timer and returns the earliest expires_next but - * does not set cpu_base::*expires_next, that is done by hrtimer_reprogram. + * Recomputes cpu_base::*next_timer and returns the earliest expires_next + * but does not set cpu_base::*expires_next, that is done by + * hrtimer[_force]_reprogram and hrtimer_interrupt only. When updating + * cpu_base::*expires_next right away, reprogramming logic would no longer + * work. * * When a softirq is pending, we can ignore the HRTIMER_ACTIVE_SOFT bases, * those timers will get run whenever the softirq gets handled, at the end of @@ -588,6 +591,37 @@ __hrtimer_get_next_event(struct hrtimer_cpu_base *cpu_base, unsigned int active_ return expires_next; } +static ktime_t hrtimer_update_next_event(struct hrtimer_cpu_base *cpu_base) +{ + ktime_t expires_next, soft = KTIME_MAX; + + /* + * If the soft interrupt has already been activated, ignore the + * soft bases. They will be handled in the already raised soft + * interrupt. + */ + if (!cpu_base->softirq_activated) { + soft = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_SOFT); + /* + * Update the soft expiry time. clock_settime() might have + * affected it. + */ + cpu_base->softirq_expires_next = soft; + } + + expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_HARD); + /* + * If a softirq timer is expiring first, update cpu_base->next_timer + * and program the hardware with the soft expiry time. + */ + if (expires_next > soft) { + cpu_base->next_timer = cpu_base->softirq_next_timer; + expires_next = soft; + } + + return expires_next; +} + static inline ktime_t hrtimer_update_base(struct hrtimer_cpu_base *base) { ktime_t *offs_real = &base->clock_base[HRTIMER_BASE_REALTIME].offset; @@ -628,23 +662,7 @@ hrtimer_force_reprogram(struct hrtimer_cpu_base *cpu_base, int skip_equal) { ktime_t expires_next; - /* - * Find the current next expiration time. - */ - expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL); - - if (cpu_base->next_timer && cpu_base->next_timer->is_soft) { - /* - * When the softirq is activated, hrtimer has to be - * programmed with the first hard hrtimer because soft - * timer interrupt could occur too late. - */ - if (cpu_base->softirq_activated) - expires_next = __hrtimer_get_next_event(cpu_base, - HRTIMER_ACTIVE_HARD); - else - cpu_base->softirq_expires_next = expires_next; - } + expires_next = hrtimer_update_next_event(cpu_base); if (skip_equal && expires_next == cpu_base->expires_next) return; @@ -1644,8 +1662,8 @@ retry: __hrtimer_run_queues(cpu_base, now, flags, HRTIMER_ACTIVE_HARD); - /* Reevaluate the clock bases for the next expiry */ - expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL); + /* Reevaluate the clock bases for the [soft] next expiry */ + expires_next = hrtimer_update_next_event(cpu_base); /* * Store the new expiry value so the migration code can verify * against it. ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [tip: timers/urgent] hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() 2021-02-23 16:02 ` [PATCH] hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() Anna-Maria Behnsen ` (2 preceding siblings ...) 2021-03-06 12:00 ` tip-bot2 for Anna-Maria Behnsen @ 2021-03-08 8:41 ` tip-bot2 for Anna-Maria Behnsen 3 siblings, 0 replies; 12+ messages in thread From: tip-bot2 for Anna-Maria Behnsen @ 2021-03-08 8:41 UTC (permalink / raw) To: linux-tip-commits Cc: Mikael Beckius, Thomas Gleixner, Anna-Maria Behnsen, Ingo Molnar, x86, linux-kernel The following commit has been merged into the timers/urgent branch of tip: Commit-ID: 46eb1701c046cc18c032fa68f3c8ccbf24483ee4 Gitweb: https://git.kernel.org/tip/46eb1701c046cc18c032fa68f3c8ccbf24483ee4 Author: Anna-Maria Behnsen <anna-maria@linutronix.de> AuthorDate: Tue, 23 Feb 2021 17:02:40 +01:00 Committer: Ingo Molnar <mingo@kernel.org> CommitterDate: Mon, 08 Mar 2021 09:37:01 +01:00 hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() hrtimer_force_reprogram() and hrtimer_interrupt() invokes __hrtimer_get_next_event() to find the earliest expiry time of hrtimer bases. __hrtimer_get_next_event() does not update cpu_base::[softirq_]_expires_next to preserve reprogramming logic. That needs to be done at the callsites. hrtimer_force_reprogram() updates cpu_base::softirq_expires_next only when the first expiring timer is a softirq timer and the soft interrupt is not activated. That's wrong because cpu_base::softirq_expires_next is left stale when the first expiring timer of all bases is a timer which expires in hard interrupt context. hrtimer_interrupt() does never update cpu_base::softirq_expires_next which is wrong too. That becomes a problem when clock_settime() sets CLOCK_REALTIME forward and the first soft expiring timer is in the CLOCK_REALTIME_SOFT base. Setting CLOCK_REALTIME forward moves the clock MONOTONIC based expiry time of that timer before the stale cpu_base::softirq_expires_next. cpu_base::softirq_expires_next is cached to make the check for raising the soft interrupt fast. In the above case the soft interrupt won't be raised until clock monotonic reaches the stale cpu_base::softirq_expires_next value. That's incorrect, but what's worse it that if the softirq timer becomes the first expiring timer of all clock bases after the hard expiry timer has been handled the reprogramming of the clockevent from hrtimer_interrupt() will result in an interrupt storm. That happens because the reprogramming does not use cpu_base::softirq_expires_next, it uses __hrtimer_get_next_event() which returns the actual expiry time. Once clock MONOTONIC reaches cpu_base::softirq_expires_next the soft interrupt is raised and the storm subsides. Change the logic in hrtimer_force_reprogram() to evaluate the soft and hard bases seperately, update softirq_expires_next and handle the case when a soft expiring timer is the first of all bases by comparing the expiry times and updating the required cpu base fields. Split this functionality into a separate function to be able to use it in hrtimer_interrupt() as well without copy paste. Fixes: 5da70160462e ("hrtimer: Implement support for softirq based hrtimers") Reported-by: Mikael Beckius <mikael.beckius@windriver.com> Suggested-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Mikael Beckius <mikael.beckius@windriver.com> Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20210223160240.27518-1-anna-maria@linutronix.de --- kernel/time/hrtimer.c | 60 +++++++++++++++++++++++++++--------------- 1 file changed, 39 insertions(+), 21 deletions(-) diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index 743c852..788b9d1 100644 --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -546,8 +546,11 @@ static ktime_t __hrtimer_next_event_base(struct hrtimer_cpu_base *cpu_base, } /* - * Recomputes cpu_base::*next_timer and returns the earliest expires_next but - * does not set cpu_base::*expires_next, that is done by hrtimer_reprogram. + * Recomputes cpu_base::*next_timer and returns the earliest expires_next + * but does not set cpu_base::*expires_next, that is done by + * hrtimer[_force]_reprogram and hrtimer_interrupt only. When updating + * cpu_base::*expires_next right away, reprogramming logic would no longer + * work. * * When a softirq is pending, we can ignore the HRTIMER_ACTIVE_SOFT bases, * those timers will get run whenever the softirq gets handled, at the end of @@ -588,6 +591,37 @@ __hrtimer_get_next_event(struct hrtimer_cpu_base *cpu_base, unsigned int active_ return expires_next; } +static ktime_t hrtimer_update_next_event(struct hrtimer_cpu_base *cpu_base) +{ + ktime_t expires_next, soft = KTIME_MAX; + + /* + * If the soft interrupt has already been activated, ignore the + * soft bases. They will be handled in the already raised soft + * interrupt. + */ + if (!cpu_base->softirq_activated) { + soft = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_SOFT); + /* + * Update the soft expiry time. clock_settime() might have + * affected it. + */ + cpu_base->softirq_expires_next = soft; + } + + expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_HARD); + /* + * If a softirq timer is expiring first, update cpu_base->next_timer + * and program the hardware with the soft expiry time. + */ + if (expires_next > soft) { + cpu_base->next_timer = cpu_base->softirq_next_timer; + expires_next = soft; + } + + return expires_next; +} + static inline ktime_t hrtimer_update_base(struct hrtimer_cpu_base *base) { ktime_t *offs_real = &base->clock_base[HRTIMER_BASE_REALTIME].offset; @@ -628,23 +662,7 @@ hrtimer_force_reprogram(struct hrtimer_cpu_base *cpu_base, int skip_equal) { ktime_t expires_next; - /* - * Find the current next expiration time. - */ - expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL); - - if (cpu_base->next_timer && cpu_base->next_timer->is_soft) { - /* - * When the softirq is activated, hrtimer has to be - * programmed with the first hard hrtimer because soft - * timer interrupt could occur too late. - */ - if (cpu_base->softirq_activated) - expires_next = __hrtimer_get_next_event(cpu_base, - HRTIMER_ACTIVE_HARD); - else - cpu_base->softirq_expires_next = expires_next; - } + expires_next = hrtimer_update_next_event(cpu_base); if (skip_equal && expires_next == cpu_base->expires_next) return; @@ -1644,8 +1662,8 @@ retry: __hrtimer_run_queues(cpu_base, now, flags, HRTIMER_ACTIVE_HARD); - /* Reevaluate the clock bases for the next expiry */ - expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL); + /* Reevaluate the clock bases for the [soft] next expiry */ + expires_next = hrtimer_update_next_event(cpu_base); /* * Store the new expiry value so the migration code can verify * against it. ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [tip: timers/urgent] hrtimer: Update softirq_expires_next correctly in hrtimer_force_reprogram() 2021-01-28 14:02 [PATCH] hrtimer: Interrupt storm on clock_settime Mikael Beckius 2021-02-05 15:45 ` Thomas Gleixner @ 2021-02-09 15:22 ` tip-bot2 for Mikael Beckius 1 sibling, 0 replies; 12+ messages in thread From: tip-bot2 for Mikael Beckius @ 2021-02-09 15:22 UTC (permalink / raw) To: linux-tip-commits Cc: Mikael Beckius, Thomas Gleixner, stable, x86, linux-kernel The following commit has been merged into the timers/urgent branch of tip: Commit-ID: 0fcc7c20d2e2a65fb5b80d42841084e8509d085d Gitweb: https://git.kernel.org/tip/0fcc7c20d2e2a65fb5b80d42841084e8509d085d Author: Mikael Beckius <mikael.beckius@windriver.com> AuthorDate: Thu, 28 Jan 2021 15:02:08 +01:00 Committer: Thomas Gleixner <tglx@linutronix.de> CommitterDate: Tue, 09 Feb 2021 16:18:42 +01:00 hrtimer: Update softirq_expires_next correctly in hrtimer_force_reprogram() hrtimer_force_reprogram() invokes __hrtimer_get_next_event() to find the earliest expiry time of all hrtimer bases. __hrtimer_get_next_event() does not update cpu_base::[softirq_]_expires_next. That needs to be done at the callsites. hrtimer_force_reprogram() updates cpu_base::softirq_expires_next only when the first expiring timer is a softirq timer and the soft interrupt is not activated. That's wrong because cpu_base::softirq_expires_next is left stale when the first expiring timer of all bases is a timer which expires in hard interrupt context. That becomes a problem when clock_settime() sets CLOCK_REALTIME forward and the first soft expiring timer is in the CLOCK_REALTIME_SOFT base. Setting CLOCK_REALTIME forward moves the clock MONOTONIC based expiry time of that timer before the stale cpu_base::softirq_expires_next. cpu_base::softirq_expires_next is cached to make the check for raising the soft interrupt fast. In the above case the soft interrupt won't be raised until clock monotonic reaches the stale cpu_base::softirq_expires_next value. That's incorrect, but what's worse it that if the softirq timer becomes the first expiring timer of all clock bases after the hard expiry timer has been handled the reprogramming of the clockevent from hrtimer_interrupt() will result in an interrupt storm. That happens because the reprogramming does not use cpu_base::softirq_expires_next, it uses __hrtimer_get_next_event() which returns the actual expiry time. Once clock MONOTONIC reaches cpu_base::softirq_expires_next the soft interrupt is raised and the storm subsides. Change the logic in hrtimer_force_reprogram() to evaluate the soft and hard bases seperately, update softirq_expires_next and handle the case when a soft expiring timer is the first of all bases by comparing the expiry times and updating the required cpu base fields. [ tglx: Modified it to avoid the double evaluation ] Fixes:5da70160462e ("hrtimer: Implement support for softirq based hrtimers") Signed-off-by: Mikael Beckius <mikael.beckius@windriver.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210128140208.30264-1-mikael.beckius@windriver.com --- kernel/time/hrtimer.c | 32 +++++++++++++++++++------------- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index 743c852..88a0145 100644 --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -626,24 +626,30 @@ static inline int hrtimer_hres_active(void) static void hrtimer_force_reprogram(struct hrtimer_cpu_base *cpu_base, int skip_equal) { - ktime_t expires_next; + ktime_t expires_next, soft = KTIME_MAX; /* - * Find the current next expiration time. + * If the soft interrupt has already been activated, ignore the + * soft bases. They will be handled in the already raised soft + * interrupt. */ - expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL); - - if (cpu_base->next_timer && cpu_base->next_timer->is_soft) { + if (!cpu_base->softirq_activated) { + soft = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_SOFT); /* - * When the softirq is activated, hrtimer has to be - * programmed with the first hard hrtimer because soft - * timer interrupt could occur too late. + * Update the soft expiry time. clock_settime() might have + * affected it. */ - if (cpu_base->softirq_activated) - expires_next = __hrtimer_get_next_event(cpu_base, - HRTIMER_ACTIVE_HARD); - else - cpu_base->softirq_expires_next = expires_next; + cpu_base->softirq_expires_next = soft; + } + + expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_HARD); + /* + * If a softirq timer is expiring first, update cpu_base->next_timer + * and program the hardware with the soft expiry time. + */ + if (expires_next > soft) { + cpu_base->next_timer = cpu_base->softirq_next_timer; + expires_next = soft; } if (skip_equal && expires_next == cpu_base->expires_next) ^ permalink raw reply related [flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-03-08 8:43 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-28 14:02 [PATCH] hrtimer: Interrupt storm on clock_settime Mikael Beckius 2021-02-05 15:45 ` Thomas Gleixner 2021-02-12 13:38 ` Sv: " Beckius, Mikael 2021-02-23 15:53 ` Anna-Maria Behnsen 2021-02-25 11:18 ` Sv: " Mikael Beckius 2021-03-01 9:13 ` Thomas Gleixner 2021-02-23 16:02 ` [PATCH] hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() Anna-Maria Behnsen 2021-02-25 11:18 ` Sv: " Mikael Beckius 2021-03-01 9:23 ` [tip: timers/urgent] " tip-bot2 for Anna-Maria Behnsen 2021-03-06 12:00 ` tip-bot2 for Anna-Maria Behnsen 2021-03-08 8:41 ` tip-bot2 for Anna-Maria Behnsen 2021-02-09 15:22 ` [tip: timers/urgent] hrtimer: Update softirq_expires_next correctly in hrtimer_force_reprogram() tip-bot2 for Mikael Beckius
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).