Currently, the cpuidle governors 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 shallow stop state on a tickless system. As
we might get stuck into shallow states even for hours, in absence of ticks
or interrupts.
To address this, We forcefully wakeup the cpu by setting the decrementer.
The decrementer is set to a value that corresponds with the residency of
the next available state. Thus firing up a timer that will forcefully
wakeup the cpu. Few such iterations will essentially train the governor to
select a deeper state for that cpu, as the timer here corresponds to the
next available cpuidle state residency. Thus, cpu will eventually end up
in the deepest possible state and we won't get stuck in a shallow state
for long duration.
Experiment
----------
For earlier versions when this feature was meat to be only for shallow lite
states, I performed experiments for three scenarios to collect some data.
case 1 :
Without this patch and without tick retained, i.e. in a upstream kernel,
It would spend more than even a second to get out of stop0_lite.
case 2 : With tick retained in a upstream kernel -
Generally, we have a sched tick at 4ms(CONF_HZ = 250). Ideally I expected
it to take 8 sched tick to get out of stop0_lite. Experimentally,
observation was
=========================================================
sample min max 99percentile
20 4ms 12ms 4ms
=========================================================
It would take atleast one sched tick to get out of stop0_lite.
case 2 : With this patch (not stopping tick, but explicitly queuing a
timer)
============================================================
sample min max 99percentile
============================================================
20 144us 192us 144us
============================================================
Description of current implementation
-------------------------------------
We calculate timeout for the current idle state as the residency value
of the next available idle state. If the decrementer is set to be
greater than this timeout, we update the decrementer value with the
residency of next available idle state. Thus, essentially training the
governor to select the next available deeper state until we reach the
deepest state. Hence, we won't get stuck unnecessarily in shallow states
for longer duration.
--------------------------------
v1 of auto-promotion : https://lkml.org/lkml/2019/3/22/58 This patch was
implemented only for shallow lite state in generic cpuidle driver.
v2 : Removed timeout_needed and rebased to current
upstream kernel
Then,
v1 of forced-wakeup : Moved the code to cpuidle powernv driver and started
as forced wakeup instead of auto-promotion
v2 : Extended the forced wakeup logic for all states.
Setting the decrementer instead of queuing up a hrtimer to implement the
logic.
v3 : 1) Cleanly handle setting the decrementer after exiting out of stop
states.
2) Added a disable_callback feature to compute timeout whenever a
state is enbaled or disabled instead of computing everytime in fast
idle path.
3) Use disable callback to recompute timeout whenever state usage
is changed for a state. Also, cleaned up the get_snooze_timeout
function.
Abhishek Goel (3):
cpuidle-powernv : forced wakeup for stop states
cpuidle : Add callback whenever a state usage is enabled/disabled
cpuidle-powernv : Recompute the idle-state timeouts when state usage
is enabled/disabled
arch/powerpc/include/asm/time.h | 2 ++
arch/powerpc/kernel/time.c | 40 ++++++++++++++++++++++++++
drivers/cpuidle/cpuidle-powernv.c | 47 ++++++++++++++++++++++---------
drivers/cpuidle/sysfs.c | 15 +++++++++-
include/linux/cpuidle.h | 5 ++++
5 files changed, 95 insertions(+), 14 deletions(-)
--
2.17.1
Currently, the cpuidle governors 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 may end up in the shallow state.
This is problematic, when the predicted state in the aforementioned
scenario is a shallow stop state on a tickless system. As we might get
stuck into shallow states for hours, in absence of ticks or interrupts.
To address this, We forcefully wakeup the cpu by setting the
decrementer. The decrementer is set to a value that corresponds with the
residency of the next available state. Thus firing up a timer that will
forcefully wakeup the cpu. Few such iterations will essentially train the
governor to select a deeper state for that cpu, as the timer here
corresponds to the next available cpuidle state residency. Thus, cpu will
eventually end up in the deepest possible state.
Signed-off-by: Abhishek Goel <redacted>
---
Auto-promotion
v1 : started as auto promotion logic for cpuidle states in generic
driver
v2 : Removed timeout_needed and rebased the code to upstream kernel
Forced-wakeup
v1 : New patch with name of forced wakeup started
v2 : Extending the forced wakeup logic for all states. Setting the
decrementer instead of queuing up a hrtimer to implement the logic.
v3 : Cleanly handle setting/resetting of decrementer so as to not break
irq work
arch/powerpc/include/asm/time.h | 2 ++
arch/powerpc/kernel/time.c | 40 +++++++++++++++++++++++++++++++
drivers/cpuidle/cpuidle-powernv.c | 32 +++++++++++++++++++++++++
3 files changed, 74 insertions(+)
To force wakeup a cpu, we need to compute the timeout in the fast idle
path as a state may be enabled or disabled but there did not exist a
feedback to driver when a state is enabled or disabled.
This patch adds a callback whenever a state_usage records a store for
disable attribute.
Signed-off-by: Abhishek Goel <redacted>
---
drivers/cpuidle/sysfs.c | 15 ++++++++++++++-
include/linux/cpuidle.h | 4 ++++
2 files changed, 18 insertions(+), 1 deletion(-)
The disable callback can be used to compute timeout for other states
whenever a state is enabled or disabled. We store the computed timeout
in "timeout" defined in cpuidle state strucure. So, we compute timeout
only when some state is enabled or disabled and not every time in the
fast idle path.
We also use the computed timeout to get timeout for snooze, thus getting
rid of get_snooze_timeout for snooze loop.
Signed-off-by: Abhishek Goel <redacted>
---
drivers/cpuidle/cpuidle-powernv.c | 35 +++++++++++--------------------
include/linux/cpuidle.h | 1 +
2 files changed, 13 insertions(+), 23 deletions(-)
@@ -94,16 +80,20 @@ static int snooze_loop(struct cpuidle_device *dev,intindex){u64snooze_exit_time;+u64snooze_timeout=drv->states[index].timeout;++if(!snooze_timeout)+snooze_timeout=default_snooze_timeout;set_thread_flag(TIF_POLLING_NRFLAG);local_irq_enable();-snooze_exit_time=get_tb()+get_snooze_timeout(dev,drv,index);+snooze_exit_time=get_tb()+snooze_timeout;ppc64_runlatch_off();HMT_very_low();while(!need_resched()){-if(likely(snooze_timeout_en)&&get_tb()>snooze_exit_time){+if(get_tb()>snooze_exit_time){/**Taskhasnotwokenupbutweareexitingthepolling*loopanyway.Requireabarrierafterpollingis
@@ -168,7 +158,7 @@ static int stop_loop(struct cpuidle_device *dev,u64timeout_tb;intforced_wakeup=0;-timeout_tb=forced_wakeup_timeout(dev,drv,index);+timeout_tb=drv->states[index].timeout;if(timeout_tb)forced_wakeup=set_dec_before_idle(timeout_tb);
@@ -255,6 +245,7 @@ static int powernv_cpuidle_driver_init(void)*/drv->cpumask=(structcpumask*)cpu_present_mask;+drv->disable_callback=pnv_disable_callback;return0;}
@@ -414,8 +405,6 @@ static int powernv_idle_probe(void)/* Device tree can indicate more idle states */max_idle_state=powernv_add_idle_states();default_snooze_timeout=TICK_USEC*tb_ticks_per_usec;-if(max_idle_state>1)-snooze_timeout_en=true;}elsereturn-ENODEV;
@@ -50,6 +50,7 @@ struct cpuidle_state {intpower_usage;/* in mW */unsignedinttarget_residency;/* in US */booldisabled;/* disabled on all CPUs */+unsignedlonglongtimeout;/* timeout for exiting out of a state */int(*enter)(structcpuidle_device*dev,structcpuidle_driver*drv,
From: Nicholas Piggin <npiggin@gmail.com> Date: 2019-07-07 10:14:58
Abhishek Goel's on July 4, 2019 7:18 pm:
quoted hunk
Currently, the cpuidle governors 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 may end up in the shallow state.
This is problematic, when the predicted state in the aforementioned
scenario is a shallow stop state on a tickless system. As we might get
stuck into shallow states for hours, in absence of ticks or interrupts.
To address this, We forcefully wakeup the cpu by setting the
decrementer. The decrementer is set to a value that corresponds with the
residency of the next available state. Thus firing up a timer that will
forcefully wakeup the cpu. Few such iterations will essentially train the
governor to select a deeper state for that cpu, as the timer here
corresponds to the next available cpuidle state residency. Thus, cpu will
eventually end up in the deepest possible state.
Signed-off-by: Abhishek Goel <redacted>
---
Auto-promotion
v1 : started as auto promotion logic for cpuidle states in generic
driver
v2 : Removed timeout_needed and rebased the code to upstream kernel
Forced-wakeup
v1 : New patch with name of forced wakeup started
v2 : Extending the forced wakeup logic for all states. Setting the
decrementer instead of queuing up a hrtimer to implement the logic.
v3 : Cleanly handle setting/resetting of decrementer so as to not break
irq work
arch/powerpc/include/asm/time.h | 2 ++
arch/powerpc/kernel/time.c | 40 +++++++++++++++++++++++++++++++
drivers/cpuidle/cpuidle-powernv.c | 32 +++++++++++++++++++++++++
3 files changed, 74 insertions(+)
I would pass this 512 in as a parameter and put the comment in the
idle code. Timer code does not know/care.
Maybe return bool and call it try_set_dec_before_idle.
quoted hunk
+ return 0;++ set_dec(timeout);
This needs to have
if (test_irq_work_pending())
set_dec(1);
here AFAIKS
quoted hunk
++ return 1;+}++void reset_dec_after_idle(void)+{+ u64 now;+ u64 *next_tb;++ if (test_irq_work_pending())+ return;++ now = get_tb_or_rtc();+ next_tb = this_cpu_ptr(&decrementers_next_tb);+ if (now >= *next_tb)+ return;
Are you sure it's okay to escape early in this case?
Thanks,
Nick
Hi Nick,
Will post next version with the changes you have suggested.
There is a comment below.
On 07/07/2019 03:43 PM, Nicholas Piggin wrote:
Abhishek Goel's on July 4, 2019 7:18 pm:
quoted
Currently, the cpuidle governors 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 may end up in the shallow state.
This is problematic, when the predicted state in the aforementioned
scenario is a shallow stop state on a tickless system. As we might get
stuck into shallow states for hours, in absence of ticks or interrupts.
To address this, We forcefully wakeup the cpu by setting the
decrementer. The decrementer is set to a value that corresponds with the
residency of the next available state. Thus firing up a timer that will
forcefully wakeup the cpu. Few such iterations will essentially train the
governor to select a deeper state for that cpu, as the timer here
corresponds to the next available cpuidle state residency. Thus, cpu will
eventually end up in the deepest possible state.
Signed-off-by: Abhishek Goel <redacted>
---
Auto-promotion
v1 : started as auto promotion logic for cpuidle states in generic
driver
v2 : Removed timeout_needed and rebased the code to upstream kernel
Forced-wakeup
v1 : New patch with name of forced wakeup started
v2 : Extending the forced wakeup logic for all states. Setting the
decrementer instead of queuing up a hrtimer to implement the logic.
v3 : Cleanly handle setting/resetting of decrementer so as to not break
irq work
arch/powerpc/include/asm/time.h | 2 ++
arch/powerpc/kernel/time.c | 40 +++++++++++++++++++++++++++++++
drivers/cpuidle/cpuidle-powernv.c | 32 +++++++++++++++++++++++++
3 files changed, 74 insertions(+)
I would pass this 512 in as a parameter and put the comment in the
idle code. Timer code does not know/care.
Maybe return bool and call it try_set_dec_before_idle.
quoted
+ return 0;++ set_dec(timeout);
This needs to have
if (test_irq_work_pending())
set_dec(1);
here AFAIKS
quoted
++ return 1;+}++void reset_dec_after_idle(void)+{+ u64 now;+ u64 *next_tb;++ if (test_irq_work_pending())+ return;++ now = get_tb_or_rtc();+ next_tb = this_cpu_ptr(&decrementers_next_tb);+ if (now >= *next_tb)+ return;
Are you sure it's okay to escape early in this case?
Yeah, It looks safe. In power9_idle_type, we call irq_set_pending_from_srr1
which sets the irq_happened. If reason is IRQ_DEC, in __check_irq_replay,
decrementer_check_overflow will be called which will set dec to a positive
valid value.
Also, we typically disable MSR EE before entering stop. And if a decrementer
wakes us up, before we enable EE, check for pending interrupt will be done.
And we finally reset dec to a positive value before we set EE=1.