Re: cpuidle governors

[Daniel Lezcano <daniel.lezcano@linaro.org>]

On 11/22/2013 04:52 PM, Rafael J. Wysocki wrote:
> On 11/22/2013 8:45 AM, Jean Delvare wrote:
>> Hi Daniel,
>>
>> Thanks for your fast reply and sorry for my slow one :(
>>
>> Le Thursday 07 November 2013 à 14:54 +0100, Daniel Lezcano a écrit :
>>> On 11/07/2013 02:44 PM, Jean Delvare wrote:
>>>> Hi all,
>>>>
>>>> I had to work on cpuidle recently and there are two things which caused
>>>> me trouble and I'd like to discuss.
>>>>
>>>> 1* Is there no documentation about how the available governors (menu
>>>> and
>>>> ladder) work? I found good documentation of the general architecture
>>>> and
>>>> API in Documentation/cpuidle, but I am missing a description of the
>>>> internal logic of each available governor (just like
>>>> Documentation/cpu-freq/governors.txt for cpufreq.)
>>> IMO, the code review and the header description in the menu.c file is
>>> the best way to understand how the governor works.
>> OK, I'll look at the code then. But I still believe this should be
>> documented for clarity.
>>
>>> For very specific
>>> questions, try asking in the mailing list.
>> I'm doing that right now ;)
>>
>>>> Also, the
>>>> documentation says that "the kernel picks the best governor based on
>>>> governor ratings" but that's pretty vague. An explanation of how the
>>>> governors are rated would be good to have. Could this be added?
>>> Yeah, actually they are rated but depending on the system configuration
>>> one fit better than the other one. Tickless system => menu governor,
>>> Periodic system => ladder governor. Using a tickless system with the
>>> ladder governor is less efficient from a power saving POV.
>> My original issue is somewhat related to this. One customer reported to
>> us that booting with nohz=off breaks cpuidle. My own testing revealed:
>>
>> * That a kernel built without NO_HZ still gets cpuidle governor "menu".
>> This contradicts your statement above.
>> * That a NO_HZ kernel booted with nohz=off behaves differently than a
>> kernel built without NO_HZ with regards to cpuidle. Both use the "menu"
>> governor by default (while I understand they should rather not), but in
>> the latter case deep C states are reached while in the former they never
>> are. This smells like a second bug.
>>
>> I would appreciate if both bugs could get fixed.
>
> Yes, it looks like we have two separate bugs there.

Actually, the first one is a bug but not the second one.

I made some changes to select by default the menu governor with NO_HZ 
and the ladder governor without NO_HZ and wanted to remove the unneeded 
governor from the Kconfig. But we let it as it was to keep the old 
behavior. Unfortunately, the governor rating decision will always goes 
in favor of the menu governor as it is the best one even if we are *not* 
with NO_HZ. So the only way to prevent is to set in the kernel command 
line the option 'cpuidle_sysfs_switch' and from the userspace set the 
ladder governor when the system has booted.

A fix could be to remove from the configuration the governor which does 
not suit the NO_HZ option.

Another fix would be to play with the rating and change them depending 
on the NO_HZ option.

Concerning the second bug, it is not a bug but totally normal. On a 
periodic tick system, (aka NO_HZ=no), the periodic timer duration 
prevents to enter a deep idle state. The target residency for the state, 
which is never reached, should be on your system greater than the 
periodic tick duration.

Hope that helps.

   -- Daniel


>
>>   I can fill out bugzilla entries if it helps.
>
> Please do, that helps a lot.
>
> Thanks,
> Rafael
>


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog