From: Thomas Gleixner <tglx@linutronix.de>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>
Subject: Re: [PATCH 4/5] hrtimer: Kick lowres dynticks targets on timer enqueue
Date: Sun, 22 Jun 2014 15:36:54 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.10.1406221533300.5170@nanos> (raw)
In-Reply-To: <1403393357-2070-5-git-send-email-fweisbec@gmail.com>
On Sun, 22 Jun 2014, Frederic Weisbecker wrote:
> From: Viresh Kumar <viresh.kumar@linaro.org>
>
> In lowres mode, hrtimers are serviced by the tick instead of a clock
> event. It works well as long as the tick stays periodic but we must also
> make sure that the hrtimers are serviced in dynticks mode targets,
> pretty much like timer list timers do.
>
> Note that all dynticks modes are concerned: get_nohz_timer_target()
> tries not to return remote idle CPUs but there is nothing to prevent
> the elected target from entering dynticks idle mode until we lock its
> base. It's also prefectly legal to enqueue hrtimers on full dynticks CPU.
>
> So there are two requirements to correctly handle dynticks:
>
> 1) On target's tick stop time, we must not delay the next tick further
> the next hrtimer.
>
> 2) On hrtimer queue time. If the tick of the target is stopped, we must
> wake up that CPU such that it sees the new hrtimer and recalculate
> the next tick accordingly.
>
> The point 1 is well handled currently through get_nohz_timer_interrupt() and
> cmp_next_hrtimer_event().
>
> But the point 2 isn't handled at all.
>
> Fixing this is easy though as we have the necessary API ready for that.
> All we need is to call wake_up_nohz_cpu() on a target when a newly
> enqueued hrtimer requires tick rescheduling, like timer list timer do.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> ---
> kernel/hrtimer.c | 27 +++++++++++++++++++--------
> 1 file changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
> index 0e32d4e..5f30917 100644
> --- a/kernel/hrtimer.c
> +++ b/kernel/hrtimer.c
> @@ -1013,14 +1013,25 @@ int __hrtimer_start_range_ns(struct hrtimer *timer, ktime_t tim,
>
> leftmost = enqueue_hrtimer(timer, new_base);
>
> - /*
> - * Only allow reprogramming if the new base is on this CPU.
> - * (it might still be on another CPU if the timer was pending)
> - *
> - * XXX send_remote_softirq() ?
> - */
> - if (leftmost && new_base->cpu_base == &__get_cpu_var(hrtimer_bases)
> - && hrtimer_enqueue_reprogram(timer, new_base)) {
> + if (!leftmost) {
> + unlock_hrtimer_base(timer, &flags);
> + return ret;
> + }
> +
> + if (!hrtimer_is_hres_active(timer)) {
> + /*
> + * Kick to reschedule the next tick to handle the new timer
> + * on dynticks target.
> + */
> + wake_up_nohz_cpu(base->cpu_base->cpu);
The timer is queued on new_base not on base.
Thanks,
tglx
next prev parent reply other threads:[~2014-06-22 13:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-21 23:29 [PATCH 0/5] timer: Fix missing dynticks kick v2 Frederic Weisbecker
2014-06-21 23:29 ` [PATCH 1/5] timer: Store cpu-number in 'struct tvec_base' Frederic Weisbecker
2014-06-23 9:33 ` [tip:timers/core] timer: Store cpu-number in struct tvec_base tip-bot for Viresh Kumar
2014-06-21 23:29 ` [PATCH 2/5] timer: Kick dynticks targets on mod_timer*() calls Frederic Weisbecker
2014-06-23 9:34 ` [tip:timers/core] " tip-bot for Viresh Kumar
2014-06-21 23:29 ` [PATCH 3/5] hrtimer: Store cpu-number in 'struct hrtimer_cpu_base' Frederic Weisbecker
2014-06-23 9:34 ` [tip:timers/core] hrtimer: Store cpu-number in struct hrtimer_cpu_base tip-bot for Viresh Kumar
2014-06-21 23:29 ` [PATCH 4/5] hrtimer: Kick lowres dynticks targets on timer enqueue Frederic Weisbecker
2014-06-22 13:36 ` Thomas Gleixner [this message]
2014-06-23 4:44 ` Viresh Kumar
2014-06-23 8:09 ` [PATCH V2 " Viresh Kumar
2014-06-23 9:34 ` [tip:timers/core] " tip-bot for Viresh Kumar
2014-06-21 23:29 ` [PATCH 5/5] hrtimer: Remove hrtimer_enqueue_reprogram() Frederic Weisbecker
2014-06-23 9:34 ` [tip:timers/core] " tip-bot for Viresh Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.10.1406221533300.5170@nanos \
--to=tglx@linutronix.de \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®