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 0/2] Auto-promotion logic for cpuidle states Date: Fri, 22 Mar 2019 02:29:40 -0500 [thread overview] Message-ID: <20190322072942.8038-1-huntbag@linux.vnet.ibm.com> (raw) Currently, the cpuidle governors (menu/ladder) determine what idle state a 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. Motivation ---------- 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. Experiment ---------- Without this patch - It was seen that for a idle system, a cpu may remain in stop0_lite for few seconds and then directly goes to a deeper state such as stop2. With this patch - A cpu will not remain in stop0_lite for more than the residency of next available state, and thus it will go to a deeper state in conservative fashion. Using this, we may spent even less than 20 milliseconds if susbsequent stop states are enabled. In the worst case, we may end up spending more than a second, as was the case without this patch. The worst case will occur in the scenario when no other shallow states are enbaled, and only deep states are available for auto-promotion. Abhishek Goel (2): cpuidle : auto-promotion for cpuidle states cpuidle : Add auto-promotion flag to cpuidle flags arch/powerpc/include/asm/opal-api.h | 1 + drivers/cpuidle/Kconfig | 4 ++ drivers/cpuidle/cpuidle-powernv.c | 13 ++++- drivers/cpuidle/cpuidle.c | 79 ++++++++++++++++++++++++++++- drivers/cpuidle/governors/ladder.c | 3 +- drivers/cpuidle/governors/menu.c | 23 ++++++++- include/linux/cpuidle.h | 12 +++-- 7 files changed, 127 insertions(+), 8 deletions(-) -- 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 0/2] Auto-promotion logic for cpuidle states Date: Fri, 22 Mar 2019 02:29:40 -0500 [thread overview] Message-ID: <20190322072942.8038-1-huntbag@linux.vnet.ibm.com> (raw) Currently, the cpuidle governors (menu/ladder) determine what idle state a 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. Motivation ---------- 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. Experiment ---------- Without this patch - It was seen that for a idle system, a cpu may remain in stop0_lite for few seconds and then directly goes to a deeper state such as stop2. With this patch - A cpu will not remain in stop0_lite for more than the residency of next available state, and thus it will go to a deeper state in conservative fashion. Using this, we may spent even less than 20 milliseconds if susbsequent stop states are enabled. In the worst case, we may end up spending more than a second, as was the case without this patch. The worst case will occur in the scenario when no other shallow states are enbaled, and only deep states are available for auto-promotion. Abhishek Goel (2): cpuidle : auto-promotion for cpuidle states cpuidle : Add auto-promotion flag to cpuidle flags arch/powerpc/include/asm/opal-api.h | 1 + drivers/cpuidle/Kconfig | 4 ++ drivers/cpuidle/cpuidle-powernv.c | 13 ++++- drivers/cpuidle/cpuidle.c | 79 ++++++++++++++++++++++++++++- drivers/cpuidle/governors/ladder.c | 3 +- drivers/cpuidle/governors/menu.c | 23 ++++++++- include/linux/cpuidle.h | 12 +++-- 7 files changed, 127 insertions(+), 8 deletions(-) -- 2.17.1
next reply other threads:[~2019-03-22 7:31 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-03-22 7:29 Abhishek Goel [this message] 2019-03-22 7:29 ` [PATCH 0/2] Auto-promotion logic for cpuidle states 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 2019-03-22 7:29 ` [PATCH 2/2] cpuidle : Add auto-promotion flag to cpuidle flags Abhishek Goel 2019-03-22 7:29 ` Abhishek Goel -- strict thread matches above, loose matches on Subject: below -- 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 7:38 ` Abhishek 2019-03-22 7:38 ` 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=20190322072942.8038-1-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: linkBe 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.