arm64: dts: apple: t603[124]: Add "capacity-dmips-mhz" properties#514
Conversation
| i-cache-size = <0x20000>; | ||
| d-cache-size = <0x10000>; | ||
| operating-points-v2 = <&sawtooth_opp>; | ||
| capacity-dmips-mhz = <933>; |
There was a problem hiding this comment.
This looks too high to me. M3 Max e-cores clock 180 MHz slower (6.5%) than M3 Pro's so it's unlikely that they are faster than on t6030. Can you retry the benchmark with the p-cores capping maxspeed to ~3500 Mhz and ~3700 MHz to ensure it's not running at al lower p-state.
Confirmation from T6031 would be nice as well, @WhatAmISupposedToPutHere ?
There was a problem hiding this comment.
coremark on CPU core 1 at 2568 MHz: Iterations/Sec : 21939.447126
coremark on CPU core 6 at 4056 MHz: Iterations/Sec : 39909.538380
So, closer to 889 if i did the math right
There was a problem hiding this comment.
P-Core at different max freq:
coremark on CPU core 0 at 3516 MHz: Iterations/Sec : 37225.462216
coremark on CPU core 0 at 3708 MHz: Iterations/Sec : 39231.071008
coremark on CPU core 0 at 4056 MHz: Iterations/Sec : 40894.220284
E-Core:
coremark on CPU core 1 at 2568 MHz: Iterations/Sec : 23089.355807
>>> 23089*1024/40894*4056/2568
913.1632280219341
>>> 23089*1024/39231*3708/2568
870.2026630189695
>>> 23089*1024/37225*3516/2568
869.6093907345455
>>> So more like 870?
There was a problem hiding this comment.
still wondering why the p-core is so much slower. I see ~43000 Iterations/Sec on p-cores using fedora rawhide
There was a problem hiding this comment.
so the low value for 4056 MHz is probably caused by not reaching the highest p-state. I wondering whether my tests reached it.
870 still looks high but more reasonable. I think we'll have a chance to adjust it when we measure opp-microwatt for the operating-points.
There was a problem hiding this comment.
Killed kwin/wpa_supplicant/all the systemd bits and plugged in the charger, getting 22026.431718 on ecore, 42474.869036 on pcore.
There was a problem hiding this comment.
42474.869036 on pcore
Same after stopping lots of services.
22026.431718 on ecore
I still get >23000 on ecore, resulting in 870 relativized
There was a problem hiding this comment.
I still see ~24k and ~43k iterations/s when running coremark on M3 Pro in a terminal in KDE Plasma with power disconnected and ~80% charged battery. approximate 844 capacity-dmips-mhz so slightly lower than 851 I committed.
If M3 Max doesn't reach all p-states on battery maybe we should mark those as "turbo-mode" although I'm not sure if/how we make boost_enabled in cpufreq conditional on AC power.
I'm going to merge this under the assumption that the lower frequency on t6031/t6034 doesn't result in proportionate e-core performance drop.
Values determined using coremark. Signed-off-by: Yureka <yuka@yuka.dev>
yuyuyureka
force-pushed
the
t6034-capacity-dmips-mhz
branch
from
d6d0556 to
101ec0c
Compare
smbdirect_public.h contains functions which will be still be eported when we move to an smbdirect.ko. For now this uses the SMBDIRECT_USE_INLINE_C_FILES code path and marks all function as '__maybe_unused static', but this will make further changes easier. Note this generates the following things from checkpatch.pl, so I passed --ignore=FILE_PATH_CHANGES,EXPORT_SYMBOL,COMPLEX_MACRO ERROR: Macros with complex values should be enclosed in parentheses AsahiLinux#514: FILE: fs/smb/common/smbdirect/smbdirect_public.h:18: +#define __SMBDIRECT_PUBLIC__ __maybe_unused static WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable AsahiLinux#515: FILE: fs/smb/common/smbdirect/smbdirect_public.h:19: +#define __SMBDIRECT_EXPORT_SYMBOL__(__sym) WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable AsahiLinux#518: FILE: fs/smb/common/smbdirect/smbdirect_public.h:22: +#define __SMBDIRECT_EXPORT_SYMBOL__(__sym) EXPORT_SYMBOL_FOR_MODULES(__sym, "cifs,ksmbd") This is exactly what we want here, so we should ignore the checkpatch.pl problems. Cc: Steve French <smfrench@gmail.com> Cc: Tom Talpey <tom@talpey.com> Cc: Long Li <longli@microsoft.com> Cc: Namjae Jeon <linkinjeon@kernel.org> Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Signed-off-by: Stefan Metzmacher <metze@samba.org> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
3 participants
Values determined using coremark.