yes that is where i found the reference. but actually i worked it out first experimenting with the clock on the command line. then i figured maybe if it works at that slow a speed it might work with an instantaneous switch too. i found the reference in the existing patch series later.
yeah from what i remember the fab/ddr scaling is in one of the other clks, it's not being set in the kernel at least.
Yes and they gives worse performance on mbw....
I can add fab scaling easily tho but I really can't see why... I mean the default value is high so we already have the performance value set. Still searching a reason to scale down on idle... Power consumption is the same... Temp doesn't change...
Maybe just to have a proper reference implementation for this platform so it could be built upon later?
1 Like
Mhh what do you mean?
Well, my thinking is that if there is a proper implementation for this router, then someone else could later use it as a template for another platform. I guess it would not take you too long to finish it at this time.
Make the fab and DDR scaling doesn't look hard to implement.. problem is that I'm now far from the router so I can't test the changes...
actually now that i look at it is not quite right. i'm not sure about the voltages, but the L2 is not supposed to scale with the cpufreq linearly. in the current 4.19 (and the prev 4.14) implementation, it steps to the next bin of the L2 when the cpufreq matches or exceeds the L2 bin. but that isn't how it's supposed to work.
IPQ8064 is supposed to run the L2 at 384, when idle, then 1G at 600, 800, 1000, then 1.2G at 1200 and 1400. IPQ8065 is supposed to do the same, except it runs at 1.2G at 1400 and 1725 (which are the cpufreq bins that replace the top two bins of IPQ8064).
2 Likes
the voltages ( are supposed to ) shift in a similar fashion.
I wonder if it does cause any problem to scale L2 without changing the voltage...
Anyway the patch set is good... It's wrong just the data set in the dts...
Would be good to give it a try...
But still it's strange that mbw gives worse result even with high frequency forced (and so L2 Freq set to the max)
Wouldn’t it be possible to retrieve the voltage table from the source code of the stock firmware?
We already have the voltage, I need to check on what is set by default by the rpm...
not just the DTS, the code doesn't support the L2 cache scaling with a different freq to the core.
BTW you've done great work on this, been snowed under IRL and have not had the energy to work on the L2 stuff. i'm sure all the ipq806x guys out there are very appreciative.
I certainly appriciate all the hard work done by everyone in openwrt... I need an "openwrt for dummies" book to understand it all though.
1 Like
I have a short question to @facboy and @Ansuel
Does anybody knows was the L2 Scaling Issues bug fixed in 19.07.x or not?
Maybe that issue was fixed in 'master' or some other custom build?
I mean the bug discussed above where L2 Frequency scales with CPU frequency linearly instead of proper implementation (according to above post and Code Aurora 'powerctl' comments):
- 384 Mhz when idle
- 1.0 Ghz at 600, 800, 1000
- 1.2 GHz at 1400, 1725
PS: I have briefly tested my fresh 19.07 installation and found out that L2 cache frequency is strictly set to a minimum supported value of 384MHz while running CPU at 600MHz and 800MHz.
That was a very disappointing discovery.
IMHO such an artificial slowdown of the L2 cache frequency can have an extremely negative impact not only on memory bandwidth but on the soft-IRQ processing performance also.
It would be interesting to measure IRQ processing speed for the different L2 cache frequencies.
By comparing results it would be possible to evaluate the impact to the system latency and responsiveness that was introduced by the forced down-clocking of the L2 cache for 600/800MHz CPU freqs.
The only thing - I do not know how to measure soft-IRQ performance, what tool could be used to perform such tests.
19.07 / ondemand / CPU freq: min 600 max 600
L2 Cache freqs: Idle | Under max LOAD
/sys/kernel/debug/clk/acpu_l2_aux/clk_rate 384000000 384000000
/sys/kernel/debug/clk/hfpll_l2/clk_rate 1200000000 1200000000
/sys/kernel/debug/clk/hfpll_l2_div/clk_rate 600000000 600000000
/sys/kernel/debug/clk/krait_l2_pri_mux/clk_rate 384000000 > 384000000 <
/sys/kernel/debug/clk/krait_l2_sec_mux/clk_rate 384000000 384000000
19.07 / ondemand / CPU freq: min 800 max 800
L2 Cache freqs: Idle | Under max LOAD
/sys/kernel/debug/clk/acpu_l2_aux/clk_rate 384000000 384000000
/sys/kernel/debug/clk/hfpll_l2/clk_rate 1200000000 1200000000
/sys/kernel/debug/clk/hfpll_l2_div/clk_rate 600000000 600000000
/sys/kernel/debug/clk/krait_l2_pri_mux/clk_rate 384000000 > 384000000 <
/sys/kernel/debug/clk/krait_l2_sec_mux/clk_rate 384000000 384000000
1 Like
i only ever run some variant of master. but given that i posted in dec 19 and 19.07 would have been cut in jul 19, i would guess it's never been in 19.07 even if it is in master. pretty sure @Ansuel merged some variant of it into master when we updated to kernel 5.4.
the current cpufreq driver address 2 main problem
- cache can't be run a 384 with other core at 1 ghz (so anything must be at 384)
- any transition from 384 to 1.4 is first set to the low value... (384) before scaled
in theory this should fix the problems... if you still find problem they could be caused by 1 and 2 should be removed
1 Like
does someone want to do some test in the free time?
I need to test something
The test is to build a custom image with a modded cpufreq driver
Then use mbw and test if the cache scaling issue is present
I can do it.