All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v1] timer: Forward timer base before migrating timers
@ 2018-01-17 12:44 Lingutla Chandrasekhar
  2018-01-18 10:45 ` Thomas Gleixner
  0 siblings, 1 reply; 2+ messages in thread
From: Lingutla Chandrasekhar @ 2018-01-17 12:44 UTC (permalink / raw)
  To: tglx; +Cc: linux-kernel, neeraju, linux-arm-msm, Lingutla Chandrasekhar

In case when timers are migrated to a CPU, after it exits
idle, but before timer base is forwarded, either from
run_timer_softirq()/mod_timer()/add_timer_on(), it's
possible that migrated timers are queued, based on older
clock value. This can cause delays in handling those timers.

For example, consider below sequence of events:

- CPU0 timer1 expires = 59969 and base->clk = 59131. So,
  timer is queued at level 2, with next expiry for this timer
  = 60032 (due to granularity addition).
- CPU1 enters idle @60007, with next timer expiry @60020.
- CPU1 exits idle.
- CPU0 is hotplugged at 60009, and timers are migrated to
  CPU1, with new base->clk = 60007. timer1 is queued,
  based on 60007 at level 0, for immediate handling (in
  next timer softirq handling).
- CPU1's base->clk is forwarded to 60009, so, in next sched
  timer interrupt, timer1 is not handled.

The issue happens as timer wheel collects expired timers
starting from the current clk's index onwards, but migrated
timers, if enqueued, based on older clk value can result
in their index being less than clk's current index.
This can only happen if new base->clk is ahead of
timer->expires, resulting in timer being queued at
new base->clk's current index.

Signed-off-by: Lingutla Chandrasekhar <clingutla@codeaurora.org>
Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>

diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 89a9e1b4264a..f66c7ad55d7a 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1886,6 +1886,12 @@ int timers_dead_cpu(unsigned int cpu)
 		raw_spin_lock_irq(&new_base->lock);
 		raw_spin_lock_nested(&old_base->lock, SINGLE_DEPTH_NESTING);
 
+		/*
+		 * Before migrating timers, update new base clk to avoid
+		 * queueing timers based on older clock value.
+		 */
+		forward_timer_base(new_base);
+
 		BUG_ON(old_base->running_timer);
 
 		for (i = 0; i < WHEEL_SIZE; i++)
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
 a Linux Foundation Collaborative Project.

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH v1] timer: Forward timer base before migrating timers
  2018-01-17 12:44 [PATCH v1] timer: Forward timer base before migrating timers Lingutla Chandrasekhar
@ 2018-01-18 10:45 ` Thomas Gleixner
  0 siblings, 0 replies; 2+ messages in thread
From: Thomas Gleixner @ 2018-01-18 10:45 UTC (permalink / raw)
  To: Lingutla Chandrasekhar; +Cc: linux-kernel, neeraju, linux-arm-msm

On Wed, 17 Jan 2018, Lingutla Chandrasekhar wrote:

> In case when timers are migrated to a CPU, after it exits
> idle, but before timer base is forwarded, either from
> run_timer_softirq()/mod_timer()/add_timer_on(), it's
> possible that migrated timers are queued, based on older
> clock value. This can cause delays in handling those timers.
> 
> For example, consider below sequence of events:
> 
> - CPU0 timer1 expires = 59969 and base->clk = 59131. So,
>   timer is queued at level 2, with next expiry for this timer
>   = 60032 (due to granularity addition).
> - CPU1 enters idle @60007, with next timer expiry @60020.
> - CPU1 exits idle.
> - CPU0 is hotplugged at 60009, and timers are migrated to
>   CPU1, with new base->clk = 60007. timer1 is queued,
>   based on 60007 at level 0, for immediate handling (in
>   next timer softirq handling).
> - CPU1's base->clk is forwarded to 60009, so, in next sched
>   timer interrupt, timer1 is not handled.
> 
> The issue happens as timer wheel collects expired timers
> starting from the current clk's index onwards, but migrated
> timers, if enqueued, based on older clk value can result
> in their index being less than clk's current index.
> This can only happen if new base->clk is ahead of
> timer->expires, resulting in timer being queued at
> new base->clk's current index.
> 
> Signed-off-by: Lingutla Chandrasekhar <clingutla@codeaurora.org>
> Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>

That's still wrong.

The SOB chain should be:

    SOB:  Author
    SOB:  Handler/Transporter
    SOB:  Committer

So if you wrote te patch then Neeraj's SOB is wrong. If Neeraj wrote the
patch then the patch should contain a

From: Neeraj

line right at the top of the changelog.

If you both developed the patch then please use;

   Co-developed-by: Neeraj
   Signed-off-by:   Neeraj
   Signed-off-by;   You

That would make you the Author in the git commit, but still preserve the
co-authorship.

Please clarify what applies to this particular patch.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-01-18 10:45 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-17 12:44 [PATCH v1] timer: Forward timer base before migrating timers Lingutla Chandrasekhar
2018-01-18 10:45 ` Thomas Gleixner

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.