Small cores at 1500Mhz on Kernel 4.14.12-99

[dewes]

After the update to 4.14.12-99 the small cores are listing 1.5Ghz as maximum frequency on Odroid XU4. Is this correct?

Code: Select all

root@odroid:~/bin/odroid-cpu-control# uname -a
Linux odroid 4.14.12-99 #1 SMP PREEMPT Mon Jan 8 03:14:09 UTC 2018 armv7l armv7l armv7l GNU/Linux
root@odroid:~/bin/odroid-cpu-control# ./odroid-cpu-control -l
CPU0: governor ondemand current 300.00MHz       min 300.00MHz [200.00MHz]       max 1.50GHz [1.50GHz]
CPU1: governor ondemand current 300.00MHz       min 300.00MHz [200.00MHz]       max 1.50GHz [1.50GHz]
CPU2: governor ondemand current 300.00MHz       min 300.00MHz [200.00MHz]       max 1.50GHz [1.50GHz]
CPU3: governor ondemand current 300.00MHz       min 300.00MHz [200.00MHz]       max 1.50GHz [1.50GHz]
CPU4: governor ondemand current 1.80GHz min 300.00MHz [200.00MHz]       max 1.80GHz [2.00GHz]
CPU5: governor ondemand current 1.80GHz min 300.00MHz [200.00MHz]       max 1.80GHz [2.00GHz]
CPU6: governor ondemand current 1.80GHz min 300.00MHz [200.00MHz]       max 1.80GHz [2.00GHz]
CPU7: governor ondemand current 1.80GHz min 300.00MHz [200.00MHz]       max 1.80GHz [2.00GHz]

And

Code: Select all

lshw -c cpu
  *-cpu:0
       description: CPU
       product: cpu
       physical id: 0
       bus info: cpu@0
       size: 300MHz
       capacity: 1500MHz
       capabilities: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae cpufreq
  *-cpu:1
       description: CPU
       product: cpu
       physical id: 1
       bus info: cpu@1
       size: 300MHz
       capacity: 1500MHz
       capabilities: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae cpufreq
  *-cpu:2
       description: CPU
       product: cpu
       physical id: 2
       bus info: cpu@2
       size: 300MHz
       capacity: 1500MHz
       capabilities: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae cpufreq
  *-cpu:3
       description: CPU
       product: cpu
       physical id: 3
       bus info: cpu@3
       size: 300MHz
       capacity: 1500MHz
       capabilities: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae cpufreq

[rooted]

Only on the XU3-Lite, shouldn't be on the XU4

[odroid]

We've increased the KFC(Cortex-A7) cores max clock to 1.5Ghz from 1.4GHz for the XU4 series.
XU3-Lite still has 1.3Ghz max clock.

[rooted]

I stand corrected

That should have said XU3 but my keyboard automatically corrects everything I have ever typed :/

I know the lite was limited but I thought the XU3 had higher clock speed.

[mad_ady]

Yay! Been waiting for this since most of my processes run on the small cores. Now I have an incentive to move to 4.14

[rooted]

According to Samsung 1.5 GHz would be overclocked it seems; is that okay for stability?

[odroid]

We've tested it with 30pcs of XU4 cluster for a few days.
There has been no single bit error so far.
We also tried 1.6Ghz too. It was fine.
But we choose the max clock at 1.5Ghz to minimize risk.

[rooted]

They also list the big cores as 2.1 GHz, while not very sane have you ever tried this?

[odroid]

2.1Ghz on Eagle(Cortex-A15) cores was not stable enough to release it publicly.
Additionally, much more frequent thermal throttling appeared.

[mad_ady]

Are the changes done in the kernel, or via DTB? Meaning somebody who would want to go to 1.4 or 1.6 would need to edit just the DTB, or would need to recompile the kernel? If just DTB, can you share on the wiki which node(s) need to be tweaked?

[memeka]

Dtb, but there are a few places to change.
Check the GitHub repository to see how 1.5 was added, then you can add 1.6 yourself

[odroid]

You have to change the kernel source and the DT both.
https://github.com/hardkernel/linux/com ... 8e467307ff
https://github.com/hardkernel/linux/com ... 17f14386bf

[meveric]

You increase the voltage for 1.4GHz to 1.5GHz quite a bit 625mV isn't that quite much for that kind of step?

I was once handed a patch for 2.1 GHz as well and was told it was working rather good if you could keep it cool enough.
Maybe it's a matter of finding the correct voltage for it?

[odroid]

As far as I know, 1.4Ghz and 1.5Ghz should have the same voltage.
Where did you find 625mV?

Edit. I was wrong. It is 62.5mV and it seems to be fine.

Code: Select all

 &cluster_a7_opp_table {
+	opp-1500000000 {
+		opp-hz = /bits/ 64 <1500000000>;
+		opp-microvolt = <1312500>;
+		clock-latency-ns = <140000>;
+	};
 	opp-1400000000 {
 		opp-hz = /bits/ 64 <1400000000>;
 		opp-microvolt = <1250000>;
 		clock-latency-ns = <140000>;
 	};
 	opp-1300000000 {
 		opp-hz = /bits/ 64 <1300000000>;
 		opp-microvolt = <1225000>;
 		clock-latency-ns = <140000>;
 	};
 	opp-1200000000 {
 		opp-microvolt = <1175000>;
 	};
 	opp-1100000000 {
 		opp-microvolt = <1137500>;
 	};

[meveric]

ah yes 62.5mV, still it's higher compared to the previous steps.
Have you checked thermal differences between 4x1.4 GHz 100% CPU and 4x1.5GHz 100% CPU?
Wonder if that's actually noticeable.

[odroid]

It is really hard to check the thermal difference since there is no temperature sensor on Little-core CPUs.
Anyway, I will try to find how we determined the voltage for 1.5Ghz.

[moon.linux]

It was a typo copy paste error, thanks for spotting my mistake.

[phaseshifter]

alternatively you can check your cpu`s speeds with this

Code: Select all

sudo  cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq

[odroid]

The latest kernel 4.14.13 update fixed the wrong voltage settings in DT file.

[mad_ady]

I've had a bit of time to play and tried to change the patches for 1.6GHz for the little cores (I know, I'm greedy). Here's the patch against 4.14: http://paste.ubuntu.com/26539974/
But when booting, the boot process stops at:

Code: Select all

[    4.074327] device-mapper: uevent: version 1.0.3
[    4.077977] device-mapper: ioctl: 4.37.0-ioctl (2017-09-20) initialised: dm-devel@redhat.com
[    4.099310] sdhci: Secure Digital Host Controller Interface driver
[    4.104071] sdhci: Copyright(c) Pierre Ossman
[    4.108656] Synopsys Designware Multimedia Card Interface Driver
[    4.115086] dwmmc_exynos 12200000.mmc: IDMAC supports 32-bit address mode.
[    4.121379] dwmmc_exynos 12200000.mmc: Using internal DMA controller.
[    4.127618] dwmmc_exynos 12200000.mmc: Version ID is 250a
[    4.133102] dwmmc_exynos 12200000.mmc: DW MMC controller at irq 83,64 bit host data width,64 deep fifo
[    4.142488] dwmmc_exynos 12200000.mmc: allocated mmc-pwrseq
[    4.168914] mmc_host mmc0: Bus speed (slot 0) = 50000000Hz (slot req 400000Hz, actual 396825HZ div = 63)
[    4.197108] dwmmc_exynos 12220000.mmc: IDMAC supports 32-bit address mode.
[    4.202645] dwmmc_exynos 12220000.mmc: Using internal DMA controller.
[    4.209985] dwmmc_exynos 12220000.mmc: Version ID is 250a
[    4.216388] dwmmc_exynos 12220000.mmc: DW MMC controller at irq 84,64 bit host data width,64 deep fifo
[    4.244906] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 400000Hz, actual 396825HZ div = 63)

(I'm booting from emmc). So I guess it's either not complete, or not stable.

[DarkBahamut]

I suspect cpu voltage is the problem. 1.25v @ 1.6GHz is likely too low for the A7 cores. I will test on my board to see if I can encourage some life into it

Little tip for attempting overclocked freqs: If you want to avoid a no boot/kernel recovery situation when trying new speeds, you can force the kernel to bring the clusters online at the stock speeds which allows the board to boot stable, then you can enable the higher freq once in the OS. If it crashes at that point then a quick reboot gets you back to a working system so you can tweak the kernel further without needing to recover the no boot issue. I was using this method on 3.10 and it worked well. I'll link the required change for 4.14 below if you wanted to try it. It should hopefully always keep you in a bootable situation

https://github.com/Emerald-Phoenix/linu ... f3b0d7f382


EDIT: Just an update, I tested 1.6GHz (I couldn't help myself )

As expected, at 1.25v sysbench seg faults immediately (as does anything else I tried). I tried a few times then the whole OS crashed. I tested again at 1.275v, this gets a few seconds into a run but then also seg faults. I then went up to 1.300v and it now completes short sysbench runs with no errors so far. Needs more testing to confirm for sure, but upping the voltage seems to quickly improve the device stability from instant crash to happily benchmarking, more or less confirming this is only a voltage issue and thus should be easily fixed . Given what I'm seeing I guess 1.300v - 1.325v should be about the stable mark for the A7 cores at 1.6GHz.

I'll try a long stress test on my board tomorrow to see how stable this is longer term

[moon.linux]

NAK: please refrain for modify and using 1.6 GHz (little) and (2.1) GHz hack for now, sill some core changes are missing.

[odroid]

We might not officially support higher than 2.0Ghz@A15 and 1.5Ghz@A7 due to stability and heat issues.
Samsung did not recommend the little core clock higher than 1.4Ghz.

[mad_ady]

It's ok even if it's not officially supported. I'd like to play with the higher frequency a bit (because I'm using the little cores most of the time). @DarkBahamut - let me know how your test goes.

[DarkBahamut]

I tested it a bit more today and there is some stability issues at 1.6GHz. Increasing the voltage does make it more stable as all the seg faults stop and it will complete short testes no problem. However once the little cluster is under load for 5-10 minutes the kernel freezes. Further increasing the voltage up to 1.3375v makes no difference so it would appear there is something else causing the problem as noted above.

The clockspeed applies correctly though and the performance increases as expected. I noted a 6.2% performance increase in little cluster sysbench runs which is about perfect for the 6.7% clock increase. I might try further to see if I can get any luck with it.

[mad_ady]

Thanks for the stability update. Since they are not stable on long loads I think I will pass 1.6GHz and be happy with 1.5