Hi Krzysztof,
On 1/31/20 1:16 PM, Krzysztof Kozlowski wrote:
On Mon, 27 Jan 2020 at 22:55, <lukasz.luba@xxxxxxx> wrote:
From: Lukasz Luba <lukasz.luba@xxxxxxx>
Enable the Energy Model (EM) brings possibility to use Energy Aware
Scheduler (EAS). This compiles the EM but does not enable to run EAS in
default. The EAS only works with SchedUtil - a CPUFreq governor which
handles direct requests from the scheduler for the frequency change. Thus,
to make EAS working in default, the SchedUtil governor should be
configured as default CPUFreq governor.
Full stop. That's enough of needed explanation of schedutil.
OK
Although, the EAS might be enabled
in runtime, when the EM is present for CPUs, the SchedUtil is compiled and
then set as CPUFreq governor, i.e.:
echo schedutil > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo schedutil > /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor
To check if EAS is ready to work, the read output from the command below
should show '1':
cat /proc/sys/kernel/sched_energy_aware
To disable EAS in runtime simply 'echo 0' to the file above.
Not related to this commit. If you were implemeting here
schedutil/EAS, then it makes sense to post all this. However what's
the point to describe it in every defconfig change?
I will drop it.
Some test results, which stress the scheduler on Odroid-XU3:
hackbench -l 500 -s 4096
With mainline code and with this patch set.
Skip the last sentence - duplicated information.
OK
The tests have been made with and without CONFIG_PROVE_LOCKING (PL)
(which is set to =y in default exynos_defconfig)
| this patch set | mainline
The commit will be applied on its own branch so the meaning of "this
patch set" will be lost. Maybe just "before/after"?
OK
|-----------------------------------------------|---------------
| performance | SchedUtil | SchedUtil | performance
| governor | governor | governor | governor
| | w/o EAS | w/ EAS |
----------------|---------------|---------------|---------------|---------------
hackbench w/ PL | 12.7s | 11.7s | 12.0s | 13.0s - 12.2s
hackbench w/o PL| 9.2s | 8.1s | 8.2s | 9.2s - 8.4s
Why does the performance different before and after this patch?
Probably due to better locality and cache utilization. I can see that
there is ~700k context switches vs ~450k and ~160k migrations vs ~50k.
If you need to communicate two threads in different clusters, it will go
through CCI.
Mention - lower better (?). Space between number and unit... or better
mention [s] in column title.
OK
And last but not least:
Why this patch is separate from 1/3? I don't get the need of splitting them.
As mentioned in response to patch 1/3. The fist patch would create MC
domain, something different than Energy Model or EAS. The decisions in
the scheduler would be different.
I can merge 1/3 and 3/3 if you like, though.
Regards,
Lukasz
Best regards,
Krzysztof
