From: Chuansheng Liu <chuansheng.liu@intel.com>
To: dzickus@redhat.com, akpm@linux-foundation.org
Cc: mingo@kernel.org, rjw@sisk.pl, linux-kernel@vger.kernel.org,
chuansheng.liu@intel.com
Subject: [PATCH V2] watchdog: optimizing the hrtimer interval for power saving
Date: Wed, 28 Nov 2012 19:24:52 +0800 [thread overview]
Message-ID: <1354101892.15558.1699.camel@cliu38-desktop-build> (raw)
In-Reply-To: <1353602906.15558.1695.camel@cliu38-desktop-build>
By default, the watchdog threshold is 10, it means every 4s
every CPU will receive one hrtimer interrupt, for low power
device, it will cause 4-5mV power impact when device is deep
sleep.
So here want to optimize it as below:
4s + 4s + 4s + 4s + 4s
== >
1s + 9s + 9s ...
Or
1s + 1s..+ 9s + 9s ....
For soft lockup detection, it will have more than 5 chances to
hit, once one chance is successful, we will start 9s hrtimer
instead of 1s;
For hard lockup dection, it will have more than 2 chances to hit,
As Don said, the min window is 10s just when CPU is always running
as MAX frequency. In most case, the window is 60s, so we should
have much more than 2 chances.
With this patch, in most cases the hrtimer will be 9s instead
of 4s averagely. It can save the device power indeed.
Change log:
Since V1: In V1, Don pointed out, "12 seconds will miss the window
repeatedly." So here set the long period < min window 10s.
Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>
---
kernel/watchdog.c | 30 ++++++++++++++++++++++++++++--
1 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index dd4b80a..b37d682 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -125,7 +125,24 @@ static u64 get_sample_period(void)
* and hard thresholds) to increment before the
* hardlockup detector generates a warning
*/
- return get_softlockup_thresh() * ((u64)NSEC_PER_SEC / 5);
+ return get_softlockup_thresh() * ((u64)NSEC_PER_SEC / 20);
+}
+
+static u64 get_long_sample_period(void)
+{
+ /*
+ * convert watchdog_thresh from seconds to ns
+ * We want to give 5 chances to detect softlockup,
+ * for power saving, once one chance is succeeding,
+ * we can set long period to avoid power consumption.
+ * Currently, set the long sample period is:
+ * 9s = 10s - 1s, the reason is for covering the window
+ * of nmi interrupt 10s interval.
+ * So at least, for hard lockup, it has >=2 chances,
+ * for soft lockup, it has >= 5 chances.
+ *
+ */
+ return (watchdog_thresh * (u64)NSEC_PER_SEC) - get_sample_period();
}
/* Commands for resetting the watchdog */
@@ -267,6 +284,10 @@ static enum hrtimer_restart watchdog_timer_fn(struct hrtimer *hrtimer)
unsigned long touch_ts = __this_cpu_read(watchdog_touch_ts);
struct pt_regs *regs = get_irq_regs();
int duration;
+ bool is_touched;
+
+ is_touched = (__this_cpu_read(hrtimer_interrupts) ==
+ __this_cpu_read(soft_lockup_hrtimer_cnt));
/* kick the hardlockup detector */
watchdog_interrupt_count();
@@ -275,7 +296,12 @@ static enum hrtimer_restart watchdog_timer_fn(struct hrtimer *hrtimer)
wake_up_process(__this_cpu_read(softlockup_watchdog));
/* .. and repeat */
- hrtimer_forward_now(hrtimer, ns_to_ktime(get_sample_period()));
+ if (is_touched) {
+ hrtimer_forward_now(hrtimer,
+ ns_to_ktime(get_long_sample_period()));
+ } else {
+ hrtimer_forward_now(hrtimer, ns_to_ktime(get_sample_period()));
+ }
if (touch_ts == 0) {
if (unlikely(__this_cpu_read(softlockup_touch_sync))) {
--
1.7.0.4
next prev parent reply other threads:[~2012-11-28 2:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-22 16:48 [PATCH] watchdog: optimizing the hrtimer interval for power saving Chuansheng Liu
2012-11-26 20:09 ` Don Zickus
2012-11-28 0:51 ` Liu, Chuansheng
2012-11-28 11:24 ` Chuansheng Liu [this message]
2012-11-28 15:42 ` [PATCH V2] " Don Zickus
2012-11-29 0:30 ` Liu, Chuansheng
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=1354101892.15558.1699.camel@cliu38-desktop-build \
--to=chuansheng.liu@intel.com \
--cc=akpm@linux-foundation.org \
--cc=dzickus@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=rjw@sisk.pl \
/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