Re: cpuidle governors

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

On 11/22/2013 07:06 PM, Jean Delvare wrote:
> Hi Daniel,
>
> Le Friday 22 November 2013 à 17:14 +0100, Daniel Lezcano a écrit :
>> On 11/22/2013 04:52 PM, Rafael J. Wysocki wrote:
>>> On 11/22/2013 8:45 AM, Jean Delvare wrote:
>>>> 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.
>
> That's what I ended up doing, yes, but I don't like it, because 1* it's
> not as straightforward as a cpuidle.governor=xxx option and 2* I don't
> think I should have to change the governor manually in the first place.
>
>> A fix could be to remove from the configuration the governor which does
>> not suit the NO_HZ option.
>
> That's not a good idea because nohz=off can be passed on the command
> line to reenable the ticking at runtime. So the governor must be decided
> at runtime too.
>
>> Another fix would be to play with the rating and change them depending
>> on the NO_HZ option.
>
> Yes, I think this is better, because then you can honor nohz=off.

Yes, good point.

>> 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.
>
> Not sure if you read what I wrote properly. The menu governor _does_
> work at least to some degree without NO_HZ, even if it is less efficient
> than with NO_HZ (no surprise here.) What bothers me is that NO_HZ=y +
> nohz=off behaves differently than NO_HZ=n. I believe they should behave
> the same.

Yes, you are right I misunderstood it.

Thanks
   -- Daniel


-- 
  <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