mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-01 07:46:46 +07:00
9bdcb44e39
Add a new cpufreq scaling governor, called "schedutil", that uses
scheduler-provided CPU utilization information as input for making
its decisions.
Doing that is possible after commit 34e2c555f3 (cpufreq: Add
mechanism for registering utilization update callbacks) that
introduced cpufreq_update_util() called by the scheduler on
utilization changes (from CFS) and RT/DL task status updates.
In particular, CPU frequency scaling decisions may be based on
the the utilization data passed to cpufreq_update_util() by CFS.
The new governor is relatively simple.
The frequency selection formula used by it depends on whether or not
the utilization is frequency-invariant. In the frequency-invariant
case the new CPU frequency is given by
next_freq = 1.25 * max_freq * util / max
where util and max are the last two arguments of cpufreq_update_util().
In turn, if util is not frequency-invariant, the maximum frequency in
the above formula is replaced with the current frequency of the CPU:
next_freq = 1.25 * curr_freq * util / max
The coefficient 1.25 corresponds to the frequency tipping point at
(util / max) = 0.8.
All of the computations are carried out in the utilization update
handlers provided by the new governor. One of those handlers is
used for cpufreq policies shared between multiple CPUs and the other
one is for policies with one CPU only (and therefore it doesn't need
to use any extra synchronization means).
The governor supports fast frequency switching if that is supported
by the cpufreq driver in use and possible for the given policy.
In the fast switching case, all operations of the governor take
place in its utilization update handlers. If fast switching cannot
be used, the frequency switch operations are carried out with the
help of a work item which only calls __cpufreq_driver_target()
(under a mutex) to trigger a frequency update (to a value already
computed beforehand in one of the utilization update handlers).
Currently, the governor treats all of the RT and DL tasks as
"unknown utilization" and sets the frequency to the allowed
maximum when updated from the RT or DL sched classes. That
heavy-handed approach should be replaced with something more
subtle and specifically targeted at RT and DL tasks.
The governor shares some tunables management code with the
"ondemand" and "conservative" governors and uses some common
definitions from cpufreq_governor.h, but apart from that it
is stand-alone.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
28 lines
1.2 KiB
Makefile
28 lines
1.2 KiB
Makefile
ifdef CONFIG_FUNCTION_TRACER
|
|
CFLAGS_REMOVE_clock.o = $(CC_FLAGS_FTRACE)
|
|
endif
|
|
|
|
# These files are disabled because they produce non-interesting flaky coverage
|
|
# that is not a function of syscall inputs. E.g. involuntary context switches.
|
|
KCOV_INSTRUMENT := n
|
|
|
|
ifneq ($(CONFIG_SCHED_OMIT_FRAME_POINTER),y)
|
|
# According to Alan Modra <alan@linuxcare.com.au>, the -fno-omit-frame-pointer is
|
|
# needed for x86 only. Why this used to be enabled for all architectures is beyond
|
|
# me. I suspect most platforms don't need this, but until we know that for sure
|
|
# I turn this off for IA-64 only. Andreas Schwab says it's also needed on m68k
|
|
# to get a correct value for the wait-channel (WCHAN in ps). --davidm
|
|
CFLAGS_core.o := $(PROFILING) -fno-omit-frame-pointer
|
|
endif
|
|
|
|
obj-y += core.o loadavg.o clock.o cputime.o
|
|
obj-y += idle_task.o fair.o rt.o deadline.o stop_task.o
|
|
obj-y += wait.o swait.o completion.o idle.o
|
|
obj-$(CONFIG_SMP) += cpupri.o cpudeadline.o
|
|
obj-$(CONFIG_SCHED_AUTOGROUP) += auto_group.o
|
|
obj-$(CONFIG_SCHEDSTATS) += stats.o
|
|
obj-$(CONFIG_SCHED_DEBUG) += debug.o
|
|
obj-$(CONFIG_CGROUP_CPUACCT) += cpuacct.o
|
|
obj-$(CONFIG_CPU_FREQ) += cpufreq.o
|
|
obj-$(CONFIG_CPU_FREQ_GOV_SCHEDUTIL) += cpufreq_schedutil.o
|