From: tip-bot for Viresh Kumar <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, hpa@zytor.com, mingo@kernel.org,
peterz@infradead.org, viresh.kumar@linaro.org,
paulmck@linux.vnet.ibm.com, fweisbec@gmail.com,
rostedt@goodmis.org, tglx@linutronix.de,
paul.gortmaker@windriver.com
Subject: [tip:timers/core] timer: Spare IPI when deferrable timer is queued on idle remote targets
Date: Wed, 26 Feb 2014 12:07:23 -0800 [thread overview]
Message-ID: <tip-8ba14654282ed6bb386d0a2f1ab329bfb293403f@git.kernel.org> (raw)
In-Reply-To: <CAKohpomMZ0TAN2e6N76_g4ZRzxd5vZ1XfuZfxrP7GMxfTNiLVw@mail.gmail.com>
Commit-ID: 8ba14654282ed6bb386d0a2f1ab329bfb293403f
Gitweb: http://git.kernel.org/tip/8ba14654282ed6bb386d0a2f1ab329bfb293403f
Author: Viresh Kumar <viresh.kumar@linaro.org>
AuthorDate: Mon, 10 Feb 2014 17:09:54 +0100
Committer: Frederic Weisbecker <fweisbec@gmail.com>
CommitDate: Fri, 14 Feb 2014 17:59:14 +0100
timer: Spare IPI when deferrable timer is queued on idle remote targets
When a timer is enqueued or modified on a remote target, the latter is
expected to see and handle this timer on its next tick. However if the
target is idle and CONFIG_NO_HZ_IDLE=y, the CPU may be sleeping tickless
and the timer may be ignored.
wake_up_nohz_cpu() takes care of that by setting TIF_NEED_RESCHED and
sending an IPI to idle targets so that the tick is reevaluated on the
idle loop through the tick_nohz_idle_*() APIs.
Now this is all performed regardless of the power properties of the
timer. If the timer is deferrable, idle targets don't need to be woken
up. Only the next buzy tick needs to care about it, and no IPI kick
is needed for that to happen.
So lets spare the IPI on idle targets when the timer is deferrable.
Meanwhile we keep the current behaviour on full dynticks targets. We can
spare IPIs on idle full dynticks targets as well but some tricky races
against idle_cpu() must be dealt all along to make sure that the timer
is well handled after idle exit. We can deal with that later since
NO_HZ_FULL already has more important powersaving issues.
Reported-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/CAKohpomMZ0TAN2e6N76_g4ZRzxd5vZ1XfuZfxrP7GMxfTNiLVw@mail.gmail.com
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
---
kernel/timer.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/kernel/timer.c b/kernel/timer.c
index accfd24..b75e789 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -939,8 +939,15 @@ void add_timer_on(struct timer_list *timer, int cpu)
* with the timer by holding the timer base lock. This also
* makes sure that a CPU on the way to stop its tick can not
* evaluate the timer wheel.
+ *
+ * Spare the IPI for deferrable timers on idle targets though.
+ * The next busy ticks will take care of it. Except full dynticks
+ * require special care against races with idle_cpu(), lets deal
+ * with that later.
*/
- wake_up_nohz_cpu(cpu);
+ if (!tbase_get_deferrable(timer->base) || tick_nohz_full_cpu(cpu))
+ wake_up_nohz_cpu(cpu);
+
spin_unlock_irqrestore(&base->lock, flags);
}
EXPORT_SYMBOL_GPL(add_timer_on);
prev parent reply other threads:[~2014-02-26 20:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-22 11:32 Is it ok for deferrable timer wakeup the idle cpu? Lei Wen
2014-01-22 14:07 ` Thomas Gleixner
2014-01-23 5:41 ` Lei Wen
2014-01-23 5:52 ` Viresh Kumar
2014-01-23 13:35 ` Frederic Weisbecker
2014-01-23 14:20 ` Viresh Kumar
2014-01-28 13:50 ` Frederic Weisbecker
2014-02-03 6:51 ` Viresh Kumar
2014-02-10 15:35 ` Frederic Weisbecker
2014-01-29 5:27 ` Preeti Murthy
2014-01-31 16:30 ` Frederic Weisbecker
2014-02-02 16:00 ` Preeti U Murthy
2014-02-03 8:19 ` Viresh Kumar
2014-02-12 15:06 ` Frederic Weisbecker
2014-02-13 5:20 ` Viresh Kumar
2014-02-26 20:07 ` tip-bot for Viresh Kumar [this message]
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=tip-8ba14654282ed6bb386d0a2f1ab329bfb293403f@git.kernel.org \
--to=tipbot@zytor.com \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paul.gortmaker@windriver.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--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