Re: cpuidle governors

["Rafael J. Wysocki" <rafael.j.wysocki@intel.com>]

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.

>   I can fill out bugzilla entries if it helps.

Please do, that helps a lot.

Thanks,
Rafael