All of lore.kernel.org
 help / color / mirror / Atom feed
From: Abhishek Goel <huntbag@linux.vnet.ibm.com>
To: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-pm@vger.kernel.org
Cc: rjw@rjwysocki.net, daniel.lezcano@linaro.org, mpe@ellerman.id.au,
	Abhishek Goel <huntbag@linux.vnet.ibm.com>
Subject: [PATCH 1/2] cpuidle : auto-promotion for cpuidle states
Date: Fri, 22 Mar 2019 01:25:29 -0500	[thread overview]
Message-ID: <20190322062530.7586-2-huntbag@linux.vnet.ibm.com> (raw)
In-Reply-To: <20190322062530.7586-1-huntbag@linux.vnet.ibm.com>

Currently, the cpuidle governors (menu /ladder) determine what idle state
an idling CPU should enter into based on heuristics that depend on the
idle history on that CPU. Given that no predictive heuristic is perfect,
there are cases where the governor predicts a shallow idle state, hoping
that the CPU will be busy soon. However, if no new workload is scheduled
on that CPU in the near future, the CPU will end up in the shallow state.

In case of POWER, this is problematic, when the predicted state in the
aforementioned scenario is a lite stop state, as such lite states will
inhibit SMT folding, thereby depriving the other threads in the core from
using the core resources.

To address this, such lite states need to be autopromoted. The cpuidle-
core can queue timer to correspond with the residency value of the next
available state. Thus leading to auto-promotion to a deeper idle state as
soon as possible.

Signed-off-by: Abhishek Goel <huntbag@linux.vnet.ibm.com>
---
 drivers/cpuidle/cpuidle.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 2406e2655..c4d1c1b38 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -584,11 +584,8 @@ static void __cpuidle_unregister_device(struct cpuidle_device *dev)
 
 static void __cpuidle_device_init(struct cpuidle_device *dev)
 {
-	int i;
 	memset(dev->states_usage, 0, sizeof(dev->states_usage));
 	dev->last_residency = 0;
-	for (i = 0; i < CPUIDLE_STATE_MAX; i++)
-               dev->states_usage[i].disable = true;
 }
 
 /**
-- 
2.17.1


WARNING: multiple messages have this Message-ID (diff)
From: Abhishek Goel <huntbag@linux.vnet.ibm.com>
To: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-pm@vger.kernel.org
Cc: daniel.lezcano@linaro.org, rjw@rjwysocki.net,
	Abhishek Goel <huntbag@linux.vnet.ibm.com>
Subject: [PATCH 1/2] cpuidle : auto-promotion for cpuidle states
Date: Fri, 22 Mar 2019 01:25:29 -0500	[thread overview]
Message-ID: <20190322062530.7586-2-huntbag@linux.vnet.ibm.com> (raw)
In-Reply-To: <20190322062530.7586-1-huntbag@linux.vnet.ibm.com>

Currently, the cpuidle governors (menu /ladder) determine what idle state
an idling CPU should enter into based on heuristics that depend on the
idle history on that CPU. Given that no predictive heuristic is perfect,
there are cases where the governor predicts a shallow idle state, hoping
that the CPU will be busy soon. However, if no new workload is scheduled
on that CPU in the near future, the CPU will end up in the shallow state.

In case of POWER, this is problematic, when the predicted state in the
aforementioned scenario is a lite stop state, as such lite states will
inhibit SMT folding, thereby depriving the other threads in the core from
using the core resources.

To address this, such lite states need to be autopromoted. The cpuidle-
core can queue timer to correspond with the residency value of the next
available state. Thus leading to auto-promotion to a deeper idle state as
soon as possible.

Signed-off-by: Abhishek Goel <huntbag@linux.vnet.ibm.com>
---
 drivers/cpuidle/cpuidle.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 2406e2655..c4d1c1b38 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -584,11 +584,8 @@ static void __cpuidle_unregister_device(struct cpuidle_device *dev)
 
 static void __cpuidle_device_init(struct cpuidle_device *dev)
 {
-	int i;
 	memset(dev->states_usage, 0, sizeof(dev->states_usage));
 	dev->last_residency = 0;
-	for (i = 0; i < CPUIDLE_STATE_MAX; i++)
-               dev->states_usage[i].disable = true;
 }
 
 /**
-- 
2.17.1


  reply	other threads:[~2019-03-22  6:26 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-22  6:25 [PATCH 0/2] Auto-promotion logic for cpuidle states Abhishek Goel
2019-03-22  6:25 ` Abhishek Goel
2019-03-22  6:25 ` Abhishek Goel [this message]
2019-03-22  6:25   ` [PATCH 1/2] cpuidle : auto-promotion " Abhishek Goel
2019-03-22  6:25 ` [PATCH 2/2] cpuidle : Add auto-promotion flag to cpuidle flags Abhishek Goel
2019-03-22  6:25   ` Abhishek Goel
2019-03-22  7:38 ` [PATCH 0/2] Auto-promotion logic for cpuidle states Abhishek
2019-03-22  7:38   ` Abhishek
2019-03-22  7:29 Abhishek Goel
2019-03-22  7:29 ` [PATCH 1/2] cpuidle : auto-promotion " Abhishek Goel
2019-03-22  7:29   ` Abhishek Goel
2019-03-22  9:45   ` Rafael J. Wysocki
2019-03-22  9:45     ` Rafael J. Wysocki
2019-03-22 13:26     ` Daniel Lezcano
2019-03-22 13:26       ` Daniel Lezcano
2019-04-01  5:11       ` Abhishek
2019-04-01  5:11         ` Abhishek
2019-04-04 10:21         ` Daniel Lezcano
2019-04-04 10:21           ` Daniel Lezcano
2019-04-04 10:54           ` Gautham R Shenoy
2019-04-04 10:54             ` Gautham R Shenoy
2019-04-04 11:10           ` Abhishek
2019-04-04 11:10             ` Abhishek

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=20190322062530.7586-2-huntbag@linux.vnet.ibm.com \
    --to=huntbag@linux.vnet.ibm.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=rjw@rjwysocki.net \
    /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.