public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Don Zickus <dzickus@redhat.com>
To: Chuansheng Liu <chuansheng.liu@intel.com>
Cc: akpm@linux-foundation.org, mingo@kernel.org, rjw@sisk.pl,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2] watchdog: optimizing the hrtimer interval for power saving
Date: Wed, 28 Nov 2012 10:42:42 -0500	[thread overview]
Message-ID: <20121128154242.GS14805@redhat.com> (raw)
In-Reply-To: <1354101892.15558.1699.camel@cliu38-desktop-build>

On Wed, Nov 28, 2012 at 07:24:52PM +0800, Chuansheng Liu wrote:
> 
> 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.

Hmm.  My only concern is if you are solving this the right way.  The
Chrome folks wanted this threshold to be smaller like 2 seconds, which
would defeat the whole point of this patch.

It seems like a better approach would be to adjust the timer somehow when
you change c-states.  The whole point of the hard and softlockup is to
detect if scheduled code is either deadlock or hogging the cpu for too long.

If the cpu is in a deep sleep, then nothing is running, right?  Which
means nothing can deadlock or hog the cpu.  In those cases you can
probably temporarily disable the lockup detector until the cpu wakes up
from that c-state and starts scheduling code again.

In that case you can really maximize your power savings (and probably get
powerTop to stop telling everyone to disable the nmi_watchdog :-) ).

Ideally in a deep sleep you don't want any soft interrupts running, no?

Just a thought.

Cheers,
Don

  reply	other threads:[~2012-11-28 15:41 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 ` [PATCH V2] " Chuansheng Liu
2012-11-28 15:42   ` Don Zickus [this message]
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=20121128154242.GS14805@redhat.com \
    --to=dzickus@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=chuansheng.liu@intel.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