linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Schedutil scaling governor is missing time_in_state
@ 2020-07-11 17:49 A L
  2020-09-03 11:02 ` Viresh Kumar
  0 siblings, 1 reply; 2+ messages in thread
From: A L @ 2020-07-11 17:49 UTC (permalink / raw)
  To: linux-pm

Hello,

I am testing the 'schedutil' scaling govenor.

So far it seems to give good results in terms of reduced thermals and energy consumption.

One difference compared to 'ondemand' that I noticed is that /sys/devices/system/cpu/cpu*/cpufreq/stats/time_in_state is never updated. It is always empty. This creates a problem for my munin graphs that log the average CPU frequency for each core.

Example with 'ondemand'
cpu0/cpufreq/stats/time_in_state:3500000 3869872
cpu0/cpufreq/stats/time_in_state:2300000 581995
cpu0/cpufreq/stats/time_in_state:1600000 6895937
cpu0/cpufreq/stats/total_trans:1746213
cpu0/cpufreq/stats/trans_table:   From  :    To
cpu0/cpufreq/stats/trans_table:         :   3500000   2300000   1600000
cpu0/cpufreq/stats/trans_table:  3500000:         0     49335     62476
cpu0/cpufreq/stats/trans_table:  2300000:     58219         0    756854
cpu0/cpufreq/stats/trans_table:  1600000:     53591    765738         0

Example with 'schedutil'
cpu3/cpufreq/stats/time_in_state:<empty>
cpu3/cpufreq/stats/total_trans:1751092
cpu3/cpufreq/stats/trans_table:<empty>

Is this a known problem or perhaps a design choice?

This is on kernel 5.7.8 on and AMD Athlon 3000G CPU using 'acpi_cpufreq' scaling_driver.

Anders


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Schedutil scaling governor is missing time_in_state
  2020-07-11 17:49 Schedutil scaling governor is missing time_in_state A L
@ 2020-09-03 11:02 ` Viresh Kumar
  0 siblings, 0 replies; 2+ messages in thread
From: Viresh Kumar @ 2020-09-03 11:02 UTC (permalink / raw)
  To: A L; +Cc: Linux PM list, Rafael J. Wysocki

On Sat, Jul 11, 2020 at 11:22 PM A L <mail@lechevalier.se> wrote:
>
> Hello,
>
> I am testing the 'schedutil' scaling govenor.
>
> So far it seems to give good results in terms of reduced thermals and energy consumption.
>
> One difference compared to 'ondemand' that I noticed is that /sys/devices/system/cpu/cpu*/cpufreq/stats/time_in_state is never updated. It is always empty. This creates a problem for my munin graphs that log the average CPU frequency for each core.
>
> Example with 'ondemand'
> cpu0/cpufreq/stats/time_in_state:3500000 3869872
> cpu0/cpufreq/stats/time_in_state:2300000 581995
> cpu0/cpufreq/stats/time_in_state:1600000 6895937
> cpu0/cpufreq/stats/total_trans:1746213
> cpu0/cpufreq/stats/trans_table:   From  :    To
> cpu0/cpufreq/stats/trans_table:         :   3500000   2300000   1600000
> cpu0/cpufreq/stats/trans_table:  3500000:         0     49335     62476
> cpu0/cpufreq/stats/trans_table:  2300000:     58219         0    756854
> cpu0/cpufreq/stats/trans_table:  1600000:     53591    765738         0
>
> Example with 'schedutil'
> cpu3/cpufreq/stats/time_in_state:<empty>
> cpu3/cpufreq/stats/total_trans:1751092
> cpu3/cpufreq/stats/trans_table:<empty>
>
> Is this a known problem or perhaps a design choice?
>
> This is on kernel 5.7.8 on and AMD Athlon 3000G CPU using 'acpi_cpufreq' scaling_driver.

With fast switching (done from within scheduler's context) we disable
recording cpufreq stats and so
this information isn't available as such. total_trans shouldn't get
updated as well, it should be a
stale value from the time when schedutil wasn't the governor.

Here is an attempt to fix it though.

http://lore.kernel.org/lkml/cover.1599031227.git.viresh.kumar@linaro.org

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-09-03 11:14 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-11 17:49 Schedutil scaling governor is missing time_in_state A L
2020-09-03 11:02 ` Viresh Kumar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).