Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings
forked fromtorvalds/linux

Commitc52232a

Browse files
Lingutla ChandrasekharKAGA-KOKO
Lingutla Chandrasekhar
authored andcommitted
timers: Forward timer base before migrating timers
On CPU hotunplug the enqueued timers of the unplugged CPU are migrated to alive CPU. This happens from the control thread which initiated the unplug.If the CPU on which the control thread runs came out from a longer idleperiod then the base clock of that CPU might be stale because the controlthread runs prior to any event which forwards the clock.In such a case the timers from the unplugged CPU are queued on the live CPUbased on the stale clock which can cause large delays due to increasedgranularity of the outer timer wheels which are far away from base:;clock.But there is a worse problem than that. The following sequence of eventsillustrates it: - CPU0 timer1 is queued expires = 59969 and base->clk = 59131. The timer is queued at wheel level 2, with resulting expiry time = 60032 (due to level granularity). - CPU1 enters idle@60007, with next timer expiry@60020. - CPU0 is hotplugged at@60009 - CPU1 exits idle and runs the control thread which migrates the timers from CPU0 timer1 is now queued in level 0 for immediate handling in the next softirq because the requested expiry time 59969 is before CPU1 base->clk 60007 - CPU1 runs code which forwards the base clock which succeeds because the next expiring timer. which was collected at idle entry time is still set to 60020. So it forwards beyond 60007 and therefore misses to expire the migrated timer1. That timer gets expired when the wheel wraps around again, which takes between 63 and 630ms depending on the HZ setting.Address both problems by invoking forward_timer_base() for the control CPUstimer base. All other places, which might run into a similar problem(mod_timer()/add_timer_on()) already invoke forward_timer_base() to avoidthat.[ tglx: Massaged comment and changelog ]Fixes:a683f39 ("timers: Forward the wheel clock whenever possible")Co-developed-by: Neeraj Upadhyay <neeraju@codeaurora.org>Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>Signed-off-by: Lingutla Chandrasekhar <clingutla@codeaurora.org>Signed-off-by: Thomas Gleixner <tglx@linutronix.de>Cc: Anna-Maria Gleixner <anna-maria@linutronix.de>Cc: linux-arm-msm@vger.kernel.orgCc: stable@vger.kernel.orgLink:https://lkml.kernel.org/r/20180118115022.6368-1-clingutla@codeaurora.org
1 parenta4f5385 commitc52232a

File tree

1 file changed

+6
-0
lines changed

1 file changed

+6
-0
lines changed

‎kernel/time/timer.c‎

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1894,6 +1894,12 @@ int timers_dead_cpu(unsigned int cpu)
18941894
raw_spin_lock_irq(&new_base->lock);
18951895
raw_spin_lock_nested(&old_base->lock,SINGLE_DEPTH_NESTING);
18961896

1897+
/*
1898+
* The current CPUs base clock might be stale. Update it
1899+
* before moving the timers over.
1900+
*/
1901+
forward_timer_base(new_base);
1902+
18971903
BUG_ON(old_base->running_timer);
18981904

18991905
for (i=0;i<WHEEL_SIZE;i++)

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp