RE: [PATCH v3] hrtimers: calculate expires_next after all timers are executed

[vigneshr]

Hi Thomas,

In this patch, we are only setting the flag
cpu_base->in_hrtirq = 1; in hrtimer_interrupt() and not resetting it.


> @@ -1251,9 +1251,9 @@ void hrtimer_interrupt(struct clock_even
> dev->next_event.tv64 = KTIME_MAX;
>
> raw_spin_lock(&cpu_base->lock);
> + cpu_base->in_hrtirq = 1;

Since this is the case, after the hrtimer_interrupt routine completes and
new timer is started and say it happens to be leftmost,
we don't allow hrtimer_reprogram() since we bail out given that
cpu_base->in_hrtirq=1 :

timer irq comes
--->hrtimer_interrupt()
---->cpu_base->in_hrtirq flag is set
------>Interrupt is serviced

After sometime

-->__hrtimer_start_range_ns()
--->happens to be leftmost hence call hrtimer_enqueue_reprogram()
----->hrtimer_reprogram()
------->bail out since cpu_base->in_hrtirq flag is stil set

At the end of hrtimer interrupt routine, i think we should also clear this
flag.

Something like the following can be added ?

diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 8c94a55..b663653 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1251,9 +1251,9 @@ void hrtimer_interrupt(struct clock_event_device *dev)
        dev->next_event.tv64 = KTIME_MAX;

        raw_spin_lock(&cpu_base->lock);
-       cpu_base->in_hrtirq = 1;
        entry_time = now = hrtimer_update_base(cpu_base);
 retry:
+       cpu_base->in_hrtirq = 1;
        /*
         * We set expires_next to KTIME_MAX here with cpu_base->lock
         * held to prevent that a timer is enqueued in our queue via
@@ -1304,6 +1304,7 @@ retry:
         * against it.
         */
        cpu_base->expires_next = expires_next;
+       cpu_base->in_hrtirq = 0;
        raw_spin_unlock(&cpu_base->lock);

        /* Reprogramming necessary ? */

Thanks and regards,
vignesh Radhakrishnan

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/