Re: PROBLEM: Cpufreq constantly keeps frequency at maximum on 4.5-rc4

[Arto Jantunen <viiru@iki.fi>]

Arto Jantunen <viiru@iki.fi> writes:

> Rik van Riel <riel@redhat.com> writes:
>>> commit a9ceb78bc75ca47972096372ff3d48648b16317a
>>> Author: Rik van Riel <riel@redhat.com>
>>> Date:   Tue Nov 3 17:34:18 2015 -0500
>>> 
>>>     cpuidle,menu: use interactivity_req to disable polling
>>
>> I could see that patch being a little aggressive on some CPUs,
>> due to interactivity_req being corrected by the load on the
>> CPU.  Does using data->predicted_us help?
>
> I'll test this tonight and get back to you.
>
>> ---8<---
>>
>> Subject: cpuidle: use predicted_us not interactivity_req to consider polling
>>
>> The interactivity_req variable is the expected sleep time, divided
>> by the CPU load. This can be too aggressive a factor in deciding
>> whether or not to consider polling in the cpuidle state selection.
>>
>> Use the (not corrected for load) predicted_us instead.
>>
>> Signed-off-by: Rik van Riel <riel@redhat.com>
>> ---
>>  drivers/cpuidle/governors/menu.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
>> index 0742b3296673..97022ae01d2e 100644
>> --- a/drivers/cpuidle/governors/menu.c
>> +++ b/drivers/cpuidle/governors/menu.c
>> @@ -330,7 +330,7 @@ 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 (data->predicted_us > 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;
>>

This patch has no effect on the symptoms I'm seeing.

-- 
Arto Jantunen