[Bug 69821] setting CONFIG_HZ_PERIODIC locks cpu at the lowest frequency using ONDEMAND

[Bug 69821] setting CONFIG_HZ_PERIODIC locks cpu at the lowest frequency using ONDEMAND

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=69821

Lan Tianyu <tianyu.lan@intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |tianyu.lan@intel.com
          Component|Power-Processor             |cpufreq
           Assignee|acpi_power-processor@kernel |cpufreq@vger.kernel.org
                   |-bugs.osdl.org              |
            Product|ACPI                        |Power Management

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 69821] setting CONFIG_HZ_PERIODIC locks cpu at the lowest frequency using ONDEMAND

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=69821

Len Brown <lenb@kernel.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lenb@kernel.org

--- Comment #1 from Len Brown <lenb@kernel.org> ---
just curious, why are you using CONFIG_HZ_PERIODIC=y ?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 69821] setting CONFIG_HZ_PERIODIC locks cpu at the lowest frequency using ONDEMAND

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=69821

--- Comment #2 from j.fikar@gmail.com ---
Well, I was trying the new CONFIG_NO_HZ_FULL and comparing it to the two old
CONFIG_NO_HZ_IDLE and CONFIG_HZ_PERIODIC. To my surprise the oldest (and I
thought most stable and most tested) CONFIG_HZ_PERIODIC causes problems with
CPU scaling.

On the other hand, I'm aware that CONFIG_NO_HZ_IDLE is the recommended default
and that there was a lot of recent development due to the new
CONFIG_NO_HZ_FULL. 

Anyway, I think it is a bug and not expected behaviour, right?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 69821] setting CONFIG_HZ_PERIODIC locks cpu at the lowest frequency using ONDEMAND

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=69821

Zhang Rui <rui.zhang@intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rui.zhang@intel.com

--- Comment #3 from Zhang Rui <rui.zhang@intel.com> ---
ping Len...

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 69821] setting CONFIG_HZ_PERIODIC locks cpu at the lowest frequency using ONDEMAND

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=69821

--- Comment #4 from Chen Yu <yu.c.chen@intel.com> ---
CONFIG_NO_HZ_FULL  is using ktime_get to get the idle time in
get_cpu_idle_time_us, it is based on clock source,  while if the kernel config
is set with CONFIG_HZ_PERIODIC , the governor might get idle time by
jiffies(tick, minimum unit of 4 millisecond),
the former is more accurate than the latter, this might be one of the reason
for the problem. I can try to reproduce and take a look.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 69821] setting CONFIG_HZ_PERIODIC locks cpu at the lowest frequency using ONDEMAND

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=69821

--- Comment #5 from Chen Yu <yu.c.chen@intel.com> ---
There is a problem in cpufreq_governor.c on how to calculate the load
for each policy:

it uses get_cpu_idle_time to get the total idle time for current cpu, if it
is config with CONFIG_NO_HZ_FULL , it is OK, because as mentioned in #Comment
4, the time is return by ktime_get, which is always increasing. However,
it is config with CONFIG_HZ_PERIODIC , the situation would be changed,
now it uses tick count to calculate the idle time by get_cpu_idle_time_jiffy,
consider the following scenario:

At T1: 
idle_tick_1 = total_tick_1 - user_tick_1

At T2: ( T2 = T1 + 80ms):
idle_tick_2 = total_tick_2 - user_tick_2


Since current algorithm to get the idle time for the past sampling, is by
caculcating (idle_tick_2 - idle_tick_1), but since you CAN NOT guarantee that
idle_tick_2 is bigger than idle_tick_1, we might get a negative value for idle
time during the past sample, which might cause the system thinks its idle time 
is very big, and the busy time is near zero, which cause the governor to always
choose the lowest cpufreq state, which cause this problem.





There are two solutions for this problem:
1. Since the root cause for this problem is that, we should not rely on idle
tick in every sample time, but should rely on the busy time directly in each
sample, as the latter is how 'top' command implement its feature.

2. Or we can also work around it by making sure the idle_time is strictly
increasing in each sample. This solution needs minimum modification and the RFC
patch is attached.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 69821] setting CONFIG_HZ_PERIODIC locks cpu at the lowest frequency using ONDEMAND

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=69821

--- Comment #6 from Chen Yu <yu.c.chen@intel.com> ---
Created attachment 197491
  --> https://bugzilla.kernel.org/attachment.cgi?id=197491&action=edit
fix idle calc in cpufreq governor  load

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 69821] setting CONFIG_HZ_PERIODIC locks cpu at the lowest frequency using ONDEMAND

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=69821

Zhang Rui <rui.zhang@intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|cpufreq@vger.kernel.org     |yu.c.chen@intel.com

-- 
You are receiving this mail because:
You are the assignee for the bug.