Re: [PATCH] cpuidle: menu: Fall back to polling if next timer event is near

[Rafael J. Wysocki]

On Saturday, March 19, 2016 11:54:39 PM Doug Smythies wrote:
> On 2016.03.19 17:34 Rafael J. Wysocki wrote:
> 
> > Commit a9ceb78bc75c (cpuidle,menu: use interactivity_req to disable
> > polling) changed the behavior of the fallback state selection part
> > of menu_select() so it looks at interactivity_req instead of
> > data->next_timer_us when it makes its decision.  That effectively
> > caused polling to be used more often as fallback idle which led to
> > significant increases of energy consumption in some cases.
> >
> > Commit e132b9b3bc7f (cpuidle: menu: use high confidence factors
> > only when considering polling) changed that logic again to be more
> > predictable, but that didn't help with the increased energy
> > consumption problem.
> >
> > For this reason, go back to making decisions on which state to fall
> > back to based on data->next_timer_us which is the time we know for
> > sure something will happen rather than a prediction (which may be
> > inaccurate and turns out to be so often enough to be problematic).
> > However, take the target residency of the first proper idle state
> > (C1) into account, so that state is not used as the fallback one
> > if its target residency is greater than data->next_timer_us.
> >
> > Signed-off-by: Rafael J. Wysocki 
> > ---
> > 
> > Doug, can you please see if this patch helps to address the problem
> > you're seeing?
> > 
> 
> Yes, it appears to work great.
> 
> >
> > Commit e132b9b3bc7f is in linux-next only ATM, but it is a rebased
> > version of https://patchwork.kernel.org/patch/8602101/.
> 
> So, I applied it to my existing kernel 4.5-rc7 work, i.e. the not
> rebased version.
> 
> My reference = rvr7:
> Kernel 4.5-rc7 +
> Rafael's 3 patch set version 10 "cpufreq: Replace timers with utilization 
> update callbacks" +
> Rik's patch (rvr5) "cpuidle: menu: use high confidence factors only when 
> considering polling" +
> Rafael's patch from herein.
> 
> My reference: k45rc7-rjw10-rvr7
> 
> Aggregate Idle States in minutes for 2000 second test (some old data 
> re-stated for reference):
> 
> State k45rc7-rjw10k45rc7-rjw10-reverted   k45rc7-rjw10-rvr7
> 0.00  18.07   0.920.41
> 1.00  12.35   19.51   21.17
> 2.00  3.964.284.40
> 3.00  1.551.531.66
> 4.00  138.96  141.99  150.77
>   
> total 174.90  168.24  178.41
> 
> Energy:
>  Kernel 4.5-rc7-rjw10: 61983 Joules
>  Kernel 4.5-rc7-rjw10-reverted: 48409 Joules (test 2 was 55040 Joules)
> k45rc7-rjw10-rvr7: 54748 Joules
> 
> The trace data has a record low number of long durations at 71.

OK, thanks!

I'm going to apply it for 4.6, then.

Thanks,
Rafael

Re: [PATCH] cpuidle: menu: Fall back to polling if next timer event is near

[Rafael J. Wysocki]

On Saturday, March 19, 2016 11:54:39 PM Doug Smythies wrote:
> On 2016.03.19 17:34 Rafael J. Wysocki wrote:
> 
> > Commit a9ceb78bc75c (cpuidle,menu: use interactivity_req to disable
> > polling) changed the behavior of the fallback state selection part
> > of menu_select() so it looks at interactivity_req instead of
> > data->next_timer_us when it makes its decision.  That effectively
> > caused polling to be used more often as fallback idle which led to
> > significant increases of energy consumption in some cases.
> >
> > Commit e132b9b3bc7f (cpuidle: menu: use high confidence factors
> > only when considering polling) changed that logic again to be more
> > predictable, but that didn't help with the increased energy
> > consumption problem.
> >
> > For this reason, go back to making decisions on which state to fall
> > back to based on data->next_timer_us which is the time we know for
> > sure something will happen rather than a prediction (which may be
> > inaccurate and turns out to be so often enough to be problematic).
> > However, take the target residency of the first proper idle state
> > (C1) into account, so that state is not used as the fallback one
> > if its target residency is greater than data->next_timer_us.
> >
> > Signed-off-by: Rafael J. Wysocki 
> > ---
> > 
> > Doug, can you please see if this patch helps to address the problem
> > you're seeing?
> > 
> 
> Yes, it appears to work great.
> 
> >
> > Commit e132b9b3bc7f is in linux-next only ATM, but it is a rebased
> > version of https://patchwork.kernel.org/patch/8602101/.
> 
> So, I applied it to my existing kernel 4.5-rc7 work, i.e. the not
> rebased version.
> 
> My reference = rvr7:
> Kernel 4.5-rc7 +
> Rafael's 3 patch set version 10 "cpufreq: Replace timers with utilization 
> update callbacks" +
> Rik's patch (rvr5) "cpuidle: menu: use high confidence factors only when 
> considering polling" +
> Rafael's patch from herein.
> 
> My reference: k45rc7-rjw10-rvr7
> 
> Aggregate Idle States in minutes for 2000 second test (some old data 
> re-stated for reference):
> 
> State k45rc7-rjw10k45rc7-rjw10-reverted   k45rc7-rjw10-rvr7
> 0.00  18.07   0.920.41
> 1.00  12.35   19.51   21.17
> 2.00  3.964.284.40
> 3.00  1.551.531.66
> 4.00  138.96  141.99  150.77
>   
> total 174.90  168.24  178.41
> 
> Energy:
>  Kernel 4.5-rc7-rjw10: 61983 Joules
>  Kernel 4.5-rc7-rjw10-reverted: 48409 Joules (test 2 was 55040 Joules)
> k45rc7-rjw10-rvr7: 54748 Joules
> 
> The trace data has a record low number of long durations at 71.

OK, thanks!

I'm going to apply it for 4.6, then.

Thanks,
Rafael

RE: [PATCH] cpuidle: menu: Fall back to polling if next timer event is near

[Doug Smythies]

On 2016.03.19 17:34 Rafael J. Wysocki wrote:

> Commit a9ceb78bc75c (cpuidle,menu: use interactivity_req to disable
> polling) changed the behavior of the fallback state selection part
> of menu_select() so it looks at interactivity_req instead of
> data->next_timer_us when it makes its decision.  That effectively
> caused polling to be used more often as fallback idle which led to
> significant increases of energy consumption in some cases.
>
> Commit e132b9b3bc7f (cpuidle: menu: use high confidence factors
> only when considering polling) changed that logic again to be more
> predictable, but that didn't help with the increased energy
> consumption problem.
>
> For this reason, go back to making decisions on which state to fall
> back to based on data->next_timer_us which is the time we know for
> sure something will happen rather than a prediction (which may be
> inaccurate and turns out to be so often enough to be problematic).
> However, take the target residency of the first proper idle state
> (C1) into account, so that state is not used as the fallback one
> if its target residency is greater than data->next_timer_us.
>
> Signed-off-by: Rafael J. Wysocki 
> ---
> 
> Doug, can you please see if this patch helps to address the problem
> you're seeing?
> 

Yes, it appears to work great.

>
> Commit e132b9b3bc7f is in linux-next only ATM, but it is a rebased
> version of https://patchwork.kernel.org/patch/8602101/.

So, I applied it to my existing kernel 4.5-rc7 work, i.e. the not
rebased version.

My reference = rvr7:
Kernel 4.5-rc7 +
Rafael's 3 patch set version 10 "cpufreq: Replace timers with utilization 
update callbacks" +
Rik's patch (rvr5) "cpuidle: menu: use high confidence factors only when 
considering polling" +
Rafael's patch from herein.

My reference: k45rc7-rjw10-rvr7

Aggregate Idle States in minutes for 2000 second test (some old data re-stated 
for reference):

State   k45rc7-rjw10k45rc7-rjw10-reverted   k45rc7-rjw10-rvr7
0.0018.07   0.920.41
1.0012.35   19.51   21.17
2.003.964.284.40
3.001.551.531.66
4.00138.96  141.99  150.77

total   174.90  168.24  178.41

Energy:
 Kernel 4.5-rc7-rjw10: 61983 Joules
 Kernel 4.5-rc7-rjw10-reverted: 48409 Joules (test 2 was 55040 Joules)
k45rc7-rjw10-rvr7: 54748 Joules

The trace data has a record low number of long durations at 71.

... Doug

RE: [PATCH] cpuidle: menu: Fall back to polling if next timer event is near

[Doug Smythies]

On 2016.03.19 17:34 Rafael J. Wysocki wrote:

> Commit a9ceb78bc75c (cpuidle,menu: use interactivity_req to disable
> polling) changed the behavior of the fallback state selection part
> of menu_select() so it looks at interactivity_req instead of
> data->next_timer_us when it makes its decision.  That effectively
> caused polling to be used more often as fallback idle which led to
> significant increases of energy consumption in some cases.
>
> Commit e132b9b3bc7f (cpuidle: menu: use high confidence factors
> only when considering polling) changed that logic again to be more
> predictable, but that didn't help with the increased energy
> consumption problem.
>
> For this reason, go back to making decisions on which state to fall
> back to based on data->next_timer_us which is the time we know for
> sure something will happen rather than a prediction (which may be
> inaccurate and turns out to be so often enough to be problematic).
> However, take the target residency of the first proper idle state
> (C1) into account, so that state is not used as the fallback one
> if its target residency is greater than data->next_timer_us.
>
> Signed-off-by: Rafael J. Wysocki 
> ---
> 
> Doug, can you please see if this patch helps to address the problem
> you're seeing?
> 

Yes, it appears to work great.

>
> Commit e132b9b3bc7f is in linux-next only ATM, but it is a rebased
> version of https://patchwork.kernel.org/patch/8602101/.

So, I applied it to my existing kernel 4.5-rc7 work, i.e. the not
rebased version.

My reference = rvr7:
Kernel 4.5-rc7 +
Rafael's 3 patch set version 10 "cpufreq: Replace timers with utilization 
update callbacks" +
Rik's patch (rvr5) "cpuidle: menu: use high confidence factors only when 
considering polling" +
Rafael's patch from herein.

My reference: k45rc7-rjw10-rvr7

Aggregate Idle States in minutes for 2000 second test (some old data re-stated 
for reference):

State   k45rc7-rjw10k45rc7-rjw10-reverted   k45rc7-rjw10-rvr7
0.0018.07   0.920.41
1.0012.35   19.51   21.17
2.003.964.284.40
3.001.551.531.66
4.00138.96  141.99  150.77

total   174.90  168.24  178.41

Energy:
 Kernel 4.5-rc7-rjw10: 61983 Joules
 Kernel 4.5-rc7-rjw10-reverted: 48409 Joules (test 2 was 55040 Joules)
k45rc7-rjw10-rvr7: 54748 Joules

The trace data has a record low number of long durations at 71.

... Doug