All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	riel@redhat.com, Rafael Wysocki <rafael.j.wysocki@intel.com>,
	Linux PM list <linux-pm@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	arjan@linux.intel.com, Len Brown <len.brown@intel.com>,
	Daniel Lezcano <daniel.lezcano@linaro.org>
Subject: Re: [PATCH 2/3] cpuidle,menu: use interactivity_req to disable polling
Date: Wed, 13 Jan 2016 23:07:46 +0100	[thread overview]
Message-ID: <3835535.S7ikxthAoE@vostro.rjw.lan> (raw)
In-Reply-To: <CAJZ5v0ipLZ3o_f_bZ=ddhvx=_OrGwzZq0bbzo7tSNbu_JDJd1Q@mail.gmail.com>

On Wednesday, January 13, 2016 10:58:13 PM Rafael J. Wysocki wrote:
> Hi,
> 
> On Wed, Jan 13, 2016 at 6:27 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> > Hi Rik,

[cut]

> >
> > diff --git i/drivers/cpuidle/governors/menu.c w/drivers/cpuidle/governors/menu.c
> > index 7b0971d97cc3..7c7f4059705a 100644
> > --- i/drivers/cpuidle/governors/menu.c
> > +++ w/drivers/cpuidle/governors/menu.c
> > @@ -330,7 +330,8 @@ static int menu_select(struct cpuidle_driver *drv,
> > struct cpuidle_device *dev)
> >          * We want to default to C1 (hlt), not to busy polling
> >          * unless the timer is happening really really soon.
> >          */
> > -       if (interactivity_req > 20 &&
> > +       if (((interactivity_req && interactivity_req > 20) ||
> 
> Well, if interactivity_req > 20, then it also is different from 0, so
> the first check should not be necessary here.
> 
> > +               data->next_timer_us > 20) &&
> 
> I guess that this simply restores the previous behavior on the
> platforms in question.
> 
> Now, the reason why it may matter is because
> CPUIDLE_DRIVER_STATE_START is 0 and so data->last_state_idx may end up
> as -1 on them.  So I think this piece of code only ever makes sense if
> CPUIDLE_DRIVER_STATE_START is 1.
> 
> >             !drv->states[CPUIDLE_DRIVER_STATE_START].disabled &&
> >                 dev->states_usage[CPUIDLE_DRIVER_STATE_START].disable == 0)
> >                 data->last_state_idx = CPUIDLE_DRIVER_STATE_START;
> > --

So I'm wondering if the appended patch helps by any chance?

Rafael

---
 drivers/cpuidle/governors/menu.c |   21 ++++++++++++---------
 1 file changed, 12 insertions(+), 9 deletions(-)

Index: linux-pm/drivers/cpuidle/governors/menu.c
===================================================================
--- linux-pm.orig/drivers/cpuidle/governors/menu.c
+++ linux-pm/drivers/cpuidle/governors/menu.c
@@ -294,8 +294,6 @@ static int menu_select(struct cpuidle_dr
 		data->needs_update = 0;
 	}
 
-	data->last_state_idx = CPUIDLE_DRIVER_STATE_START - 1;
-
 	/* Special case when user has set very strict latency requirement */
 	if (unlikely(latency_req == 0))
 		return 0;
@@ -326,14 +324,19 @@ static int menu_select(struct cpuidle_dr
 	if (latency_req > interactivity_req)
 		latency_req = interactivity_req;
 
-	/*
-	 * We want to default to C1 (hlt), not to busy polling
-	 * unless the timer is happening really really soon.
-	 */
-	if (interactivity_req > 20 &&
-	    !drv->states[CPUIDLE_DRIVER_STATE_START].disabled &&
-		dev->states_usage[CPUIDLE_DRIVER_STATE_START].disable == 0)
+	if (CPUIDLE_DRIVER_STATE_START > 0) {
+		data->last_state_idx = CPUIDLE_DRIVER_STATE_START - 1;
+		/*
+		 * We want to default to C1 (hlt), not to busy polling
+		 * unless the timer is happening really really soon.
+		 */
+		if (interactivity_req > 20 &&
+		    !drv->states[CPUIDLE_DRIVER_STATE_START].disabled &&
+			dev->states_usage[CPUIDLE_DRIVER_STATE_START].disable == 0)
+			data->last_state_idx = CPUIDLE_DRIVER_STATE_START;
+	} else {
 		data->last_state_idx = CPUIDLE_DRIVER_STATE_START;
+	}
 
 	/*
 	 * Find the idle state with the lowest power while satisfying

  reply	other threads:[~2016-01-13 22:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-03 22:34 [PATCH 0/3] cpuidle: small improvements & fixes for menu governor (resend) riel
2015-11-03 22:34 ` [PATCH 1/3] cpuidle,x86: increase forced cut-off for polling to 20us riel
2015-11-04 16:00   ` Arjan van de Ven
2015-11-03 22:34 ` [PATCH 2/3] cpuidle,menu: use interactivity_req to disable polling riel
2015-11-04 16:01   ` Arjan van de Ven
2016-01-13 17:27   ` Sudeep Holla
2016-01-13 21:58     ` Rafael J. Wysocki
2016-01-13 22:07       ` Rafael J. Wysocki [this message]
2016-01-14 10:40         ` Sudeep Holla
2016-01-15  0:46           ` Rafael J. Wysocki
2016-01-14 10:33       ` Sudeep Holla
2015-11-03 22:34 ` [PATCH 3/3] cpuidle,menu: smooth out measured_us calculation riel
2015-11-04 16:02   ` Arjan van de Ven
2015-11-05 22:34 ` [PATCH 0/3] cpuidle: small improvements & fixes for menu governor (resend) Rafael J. Wysocki
2015-11-06  2:26   ` Rik van Riel
  -- strict thread matches above, loose matches on Subject: below --
2015-10-28 22:46 [PATCH 0/3] cpuidle: small improvements & fixes for menu governor riel
2015-10-28 22:46 ` [PATCH 2/3] cpuidle,menu: use interactivity_req to disable polling riel

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=3835535.S7ikxthAoE@vostro.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=arjan@linux.intel.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rafael@kernel.org \
    --cc=riel@redhat.com \
    --cc=sudeep.holla@arm.com \
    /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 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.