Skip to contentSkip to conversation

setting CONFIG_HZ_PERIODIC locks cpu at the lowest frequency using ONDEMAND

Bug 69821 [email protected] 1 participant 8 messages Feb 7, 2014 – Dec 16, 2015 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

[email protected]

author
#1 lore raw

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

Lan Tianyu <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |ASSIGNED
                 CC|                            |[email protected]
          Component|Power-Processor             |cpufreq
           Assignee|acpi_power-processor@kernel |[email protected]
                   |-bugs.osdl.org              |
            Product|ACPI                        |Power Management
Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#2 lore raw
In reply to a message not in the archive

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

Len Brown <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #1 from Len Brown <[email protected]> --- just curious, why are you using CONFIG_HZ_PERIODIC=y ?

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#3 lore raw
In reply to a message not in the archive

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

--- Comment #2 from [email protected] ---
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?

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#5 lore raw
In reply to a message not in the archive

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

--- Comment #4 from Chen Yu <[email protected]> --- 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.

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#6 lore raw
In reply to a message not in the archive

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

--- Comment #5 from Chen Yu <[email protected]> --- 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.

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.