retrigger_next_event() is defined within #ifdef CONFIG_HIGH_RES_TIMERS as we
already have pointer to base available. So it makes more sense to simple use
base->hres_active instead of doing this by calling hrtimer_hres_active():
__this_cpu_read(hrtimer_bases.hres_active)
Also the same reason apply to code in __remove_hrtimer().
There is one more noticeable issue with __remove_hrtimer() without this patch.
We are checking hres_active of *this cpu's* base, where as it is not guanrateed
at all that __remove_hrtimer() would be called on this CPU. Specially from the
migration code, timer's CPU is already down.
Signed-off-by: Viresh Kumar <[email protected]>
---
kernel/hrtimer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index b0fbf12..ad5b7ba 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -672,7 +672,7 @@ static void retrigger_next_event(void *arg)
{
struct hrtimer_cpu_base *base = &__get_cpu_var(hrtimer_bases);
- if (!hrtimer_hres_active())
+ if (!base->hres_active)
return;
raw_spin_lock(&base->lock);
@@ -897,7 +897,7 @@ static void __remove_hrtimer(struct hrtimer *timer,
if (&timer->node == next_timer) {
#ifdef CONFIG_HIGH_RES_TIMERS
/* Reprogram the clock event device. if enabled */
- if (reprogram && hrtimer_hres_active()) {
+ if (reprogram && base->cpu_base->hres_active) {
ktime_t expires;
expires = ktime_sub(hrtimer_get_expires(timer),
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
