lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 23 Jun 2020 21:02:38 +0200 From: Krzysztof Kozlowski <krzk@...nel.org> To: Willy Wolff <willy.mh.wolff.ml@...il.com> Cc: Chanwoo Choi <cw00.choi@...sung.com>, MyungJoo Ham <myungjoo.ham@...sung.com>, Kyungmin Park <kyungmin.park@...sung.com>, Kukjin Kim <kgene@...nel.org>, linux-pm@...r.kernel.org, "linux-samsung-soc@...r.kernel.org" <linux-samsung-soc@...r.kernel.org>, linux-arm-kernel@...ts.infradead.org, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: brocken devfreq simple_ondemand for Odroid XU3/4? On Tue, 23 Jun 2020 at 18:47, Willy Wolff <willy.mh.wolff.ml@...il.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. > > Results: > 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? Best regards, Krzysztof
Powered by blists - more mailing lists