brocken devfreq simple_ondemand for Odroid XU3/4?
krzk at kernel.org
Tue Jun 23 15:02:38 EDT 2020
On Tue, 23 Jun 2020 at 18:47, Willy Wolff <willy.mh.wolff.ml at gmail.com> wrote:
> Hi everybody,
> Is DVFS for memory bus really working on Odroid XU3/4 board?
> Using a simple microbenchmark that is doing only memory accesses, memory DVFS
> seems to not working properly:
> The microbenchmark is doing pointer chasing by following index in an array.
> Indices in the array are set to follow a random pattern (cutting prefetcher),
> and forcing RAM access.
> git clone https://github.com/wwilly/benchmark.git \
> && cd benchmark \
> && source env.sh \
> && ./bench_build.sh \
> && bash source/scripts/test_dvfs_mem.sh
> Python 3, cmake and sudo rights are required.
> DVFS CPU with performance governor
> mem_gov = simple_ondemand at 165000000 Hz in idle, should be bumped when the
> benchmark is running.
> - on the LITTLE cluster it takes 4.74308 s to run (683.004 c per memory access),
> - on the big cluster it takes 4.76556 s to run (980.343 c per moemory access).
> While forcing DVFS memory bus to use performance governor,
> mem_gov = performance at 825000000 Hz in idle,
> - on the LITTLE cluster it takes 1.1451 s to run (164.894 c per memory access),
> - on the big cluster it takes 1.18448 s to run (243.664 c per memory access).
> The kernel used is the last 5.7.5 stable with default exynos_defconfig.
Thanks for the report. Few thoughts:
1. What trans_stat are saying? Except DMC driver you can also check
all other devfreq devices (e.g. wcore) - maybe the devfreq events
(nocp) are not properly assigned?
2. Try running the measurement for ~1 minutes or longer. The counters
might have some delay (which would require probably fixing but the
point is to narrow the problem).
3. What do you understand by "mem_gov"? Which device is it?
More information about the linux-arm-kernel