Setting 1000000 on 3rd and 6th positions of each opp caused all opp having higher configured voltage to be rejected and not to appear in the list of configurable ones:
[ 3.308512] core: _opp_supported_by_regulators: OPP minuV: 1025000 maxuV: 1000000, not supported by regulator
[ 3.308516] cpu cpu4: _opp_add: OPP not supported by regulators (2208102500)
I still don’t understand how that’s mapped, the only regulator I found was the rk806 that has a 1050mV configured limit. /me still puzzled.
Also, with that 1V value at these positions I’m only having the CPU run at 394 MHz now.
Strangely having a small difference between values at 1,2,4,5 and 3,6 seldom works. Only 1025/1037 and 1037/1050 do work, and provide me with 2314 and 2334 MHz measured respectively. This is still quite confusing, I really don’t understand how that regulator setting works.
But didn’t we know this already end of September when @amazingfate and me explored a bit ‘overclocking’ which turned out to be ‘overvolting’ in reality and letting do PVTM the rest?
When defining the voltages back then I only adjusted most right column like here and it worked. To use voltages higher than 1050mV regulator-max-microvolt needs to be adjusted.
I’m particularly surprised to see that the frequency seems to be completely ignored and only the voltage is used. It’s as if they were just using a VCO (after all that’s what a PLL is made of, but…).
I find it annoying not to understand how this stuff works internally. It’s certain it’s doing very dumb things and is far from being smart. We’d just need to figure the formula to know how to properly configure a CPU for a given frequency based on the measured PVTM values. It feels to me that I could possibly emit dangerous values and get something working everywhere, but do we want to blindly do that ? I don’t think so. Maybe some of the voltages concern transitions between previous and current mode. I don’t know. Last time I checked the code I got lost.
I went through sbc-bench results collection (~190 RK3588/RK3588s results) to create a table (trying to filter out @amazingfate’s overvolting attempts) with pvtm values ranging from 1629 to 1805 for the A76. Here’s the table.
Unfortunately in the past the OPP tables were only included in sbc-bench results when using MODE=extensive. I changed that now. So some of the results in the table might be the results of manual overvolting.
And since Radxa’s cosmetical change I could also deleted the cpufreq OPP column since regardless of PVTM distribution all RK3588 got the 2400 MHz OPP granted.
Looking at the different devices is interesting: RK3588S in Khadas Edge 2 shows up only with low pvtm values but also with very high idle temperatures (combined with rather low temperatures after executing the benchmark which hints at using their fansink). Also almost always the A76 end up being clocked at just 395 MHz during ‘full CPU utilization’ (running the 7-zip benchmark):
The 395 MHz is quite annoying, I’ve met it a few times already during my experimentations. I noticed that my changes were not consistently accepted across reboots, and that sometimes a power cycle was needed, and even sometimes some power cycles didn’t help. I suspect that the existence of other OPPs that are conditioned by PVTM values which may change between boots have an impact. There might be some bugs in the regulator or opp code that makes some opps conflict with others. It would be nice if we could make sure nobody meets the 395 MHz by accident anymore.
Anyway I thought I would barge in with a tangential that as with big.Little layouts the schedulers don’t make sense especially the default ordering of the cores would always seem the wrong way round.
Also with affinity near everything seems to be running on core 0 and being lazy (in fact wanting dynamic) I installed irqbalance which has seen some improvements.
The default scheduling core and irq affinity is pretty bad and wondered if you guys had any solutions?
The device DT contains capacity-dmips-mhz = <530>; for the A55 and capacity-dmips-mhz = <1024>; for the A76 as such the scheduler should prefer the latter for jobs. Works just fine for me (using ondemandfor reasons):
Wrt IRQ affinity I would believe the best is static mappings suitable for different use cases (moving e.g. PCIe and USB3 interrupts away from cpu0 to another little core).
Seems fairly balanced for the irqs used now and don’t have to think of static requirements.
The default scheduling is just me musing how badly the ondemand scheduler does in regards to the running Glmark2 than running the performance scheduler.
Its ok if it hits a solid wall of load where the demand threshold is hit on a smaller it swaps out to big.
If you get varying load across cores then that sampling of starting on small at low frequency and ramping up then jumping to big and doing the same.
I was just sat here thinking why can it not start big and ramp down or if there was an implementation and how do you swap from the default CFS scheduler (we are using that?) to either
or
Purely out of interest and wondered if you guys knew?
[edit]
The more I look and think about it, the more I don’t get big.Liitle especially when they are linked into profiles where all 4 cpu’s ramp up and down together, with 2 groups of big that ramp up together.
You can do something really weird and leave profile 0 as is but lower the /ondemand/up_threshold of the x2 big to some silly low value such as 3%.
Then when you run something like glmark2 you get a score near what a performance governor would give but also the cpu’s ramp down when not in use.
Also even though there is practically no load on profile 0 all 4 cpu’s are often ramping up to the top end opp frequencies, which prob makes sense on a phone but as a mains powered SBC it just confuses me.
Thanks! It’s very useful!!!
Can you provid your info of dmesg | grep cpu.cpu
Something really confuse me,for example:
3.5.1 Modify Voltage According to Leakage
Background: we find that the Vmin of small leakage chips is larger than big leakage chips from test, so we can
reduce the voltage for big leakage chips to reduce power consumption and improve performance.
It just depends on chip generations. Older ones were measuring leakage in the fab and using that to adjust voltage. Newer ones use PVTM to measure it at boot time.
~$ dmesg|grep cpu.cpu
[ 4.706906] cpu cpu0: leakage=14
[ 4.706927] cpu cpu0: Looking up cpu-supply from device tree
[ 4.708386] cpu cpu0: pvtm=1481
[ 4.708476] cpu cpu0: pvtm-volt-sel=3
[ 4.708503] cpu cpu0: Looking up cpu-supply from device tree
[ 4.708619] cpu cpu0: Looking up mem-supply from device tree
[ 4.708955] cpu cpu4: leakage=10
[ 4.708973] cpu cpu4: Looking up cpu-supply from device tree
[ 4.715458] cpu cpu4: pvtm=1719
[ 4.719393] cpu cpu4: pvtm-volt-sel=5
[ 4.719418] cpu cpu4: Looking up cpu-supply from device tree
[ 4.719914] cpu cpu4: Looking up mem-supply from device tree
[ 4.720625] cpu cpu6: leakage=10
[ 4.720641] cpu cpu6: Looking up cpu-supply from device tree
[ 4.727141] cpu cpu6: pvtm=1740
[ 4.731097] cpu cpu6: pvtm-volt-sel=5
[ 4.731120] cpu cpu6: Looking up cpu-supply from device tree
[ 4.731611] cpu cpu6: Looking up mem-supply from device tree
[ 4.732680] cpu cpu0: avs=0
[ 4.733371] cpu cpu4: avs=0
[ 4.734058] cpu cpu6: avs=0
One of the two big clusters is close to the boundary and randomly switches between two volt-sel values (I believe it’s the 2nd one which oscillates between 5 and 6 but it might also be the 1st one between 4 and 5, I don’t remember).
At least with the doc above I could improve the measurement time in the DT to make it more stable.
Quick test with Rock 5B (with a ‘good’ RK3588 on it: pvtm-volt-sel 5/7/7), RPi USB-C power brick, only GbE networking and Netio 4KF Powerbox measuring idle consumption:
DMC governor and all cpufreq policies set to powersave: 1280mW
just switching policy0 to performance (the four A55 idling now at ~1820 MHz instead of ~400 MHz): 1350mW
all cpufreq policies set to performance as such all CPU cores idling at highest cpufreq OPP: 1500mW
now also DMC governor set to performance: 2100mW
That’s a whopping 70mW or 17.5mW per A55 depending on whether it is doing nothing at ~400 MHz or ~1800 MHz. With the A76 the difference it makes whether they’re idling at ~400 MHz or ~2350 MHz is 150mW or 37.5mW per core. So as long as they aren’t doing anything the consumption difference with them staying on the lowest vs. highest cpufreq OPP is negligible. Now we would need another Rock 5B Rev 1.3 with a ‘weak’ RK3588 on it ( pvtm-volt-sel=2) to compare with same equipment and methodology how much of a difference this makes.
Memory is a different thing: the difference between 528 MHz and 2112 MHz is a massive 600mW compared to CPU clockspeeds. As such the DMC governor and the up_treshold setting really matter.
The small consumption difference with ARM cores doing nothing regardless of cpufreq (sitting on an ‘Wait for Interrupt’ instruction which was already there with ARMv7) might have driven the decision on ARM to have one cpufreq policy per cluster (which you call profile?) unlike on other platforms like x86_64 where each core seems to behave independently (no idea which influence the cpufreq driver on modern x86_64 implementations really has or whether it’s just reporting what something else inside an Intel/AMD CPU decides).
And I guess the decision to split the four A76 into two clusters was mostly motivated by PVTM as to be able to drive them with different supply voltages and not so much keep idle A76 on lower cpufreq OPP.
Yeah I don’t know enough but policy (apols). Arm wise I presume its setup in a similar way to the newer triple-cluster architecture and maybe one policy can push further in Mhz than the other in a similar way the core count in Intel speedstep may do? I guess really its a verybig.biG.Little config really but just uses the same for verybig & biG.
This time I am totally asking you as expecting you have measured hard data of various governors.
I have only got one of those really crappy usb-c meters and haven’t bothered to get a readout.
Using my crappy usb-c meter and a 5v pi supply as it doesn’t handle PD its telling me 3.3watt approx on idle.
Running Glmark2 as an example with no governor or taskset changes ups wattage to approx avg 4.6 watts sometimes above 6 watt but often below and prob a decent guesstimate avg and ends up with a lacklustre glmark2 Score of 582.
Doing a weird and wonderful of setting only echo 2 > sys/devices/system/cpu/cpufreq/policy4/6/ondemand/up_threshold with another horrid guesstimate wattage of approx avg 5.3 watt end seems to have the same occasional max outs of just over 6 watt with a not brilliant but ok glmark2 Score of 920.
After running it drops to that 3.3watt approx idle again.
echo performance | sudo tee /sys/bus/cpu/devices/cpu[046]/cpufreq/scaling_govenor /sys/class/devfreq/dmc/governor
Only seems to up wattage to a guesstimate of 5.8 watts whilst idle rises to 3.9 watt whilst returning a glmark2 score of 1014
Lols as yeah it makes no sense to me, but really need a logging meter to get a true avg than guesstimating it Actually just noticed it does have a resettable mWh log doh.
I encount exactly problem as you.when I set voltage bigger than 1000mv,Frequency is locked to 400mhz.
[ 476.994512] vdd_cpu_big0_s0: Restricting voltage, 1025000-1000000uV
[ 476.994567] vdd_cpu_big0_s0: Restricting voltage, 1025000-1000000uV
[ 476.994591] cpu cpu4: rockchip_cpufreq_set_volt: failed to set voltage (1025000 1025000 1025000 uV): -22
[ 476.994613] cpufreq: __target_index: Failed to change cpu frequency: -22
opp table:
opp-2400000000 {
opp-supported-hw = <0xfd 0xffff>;
opp-hz = <0x00 0x8f0d1800>;
opp-microvolt = <0xFA3E8 0xFA3E8 0xFA3E8 0xFA3E8 0xFA3E8 0xFA3E8>;
clock-latency-ns = <0x9c40>;
};
Do you have find a way to solve it?
Actually just noticed it does have a resettable mWh log doh.