<sibis928376>
Also given that the max frequency is a single/double core boost frequency, you would want the other cores in the cluster to reach idle i.e. cpu idle shouldn't be disabled in your build. Also there is a known bug that prevents schedutil from reaching these boost frequencies as seen in
<weirdtreething>
I'll have to experiment more with kernel patches
<weirdtreething>
so if I'm understanding what you said correctly, me using performance instead of schedutil would actually prevent me from reaching max performance?
<sibis928376>
No, you can still rely on performance to actually get the max performance but just ensure that cpuidle isn't turned off. Another thing to note is that boost is disabled in the kernel sysfs nodes by default turning that on should improve your scores a bit.
<weirdtreething>
I don't think cpuidle is turned off. and I did enable boost in sysfs
<sibis928376>
then ensure that you look at the cpufreq policy6/12 / stats / time in state to see if kernel has been voting for these boost frequencies
<sibis928376>
if ^^ is also true then memlat series would be the only way you can further improve your scores
<weirdtreething>
not sure how to interpret the time_in_state data
<weirdtreething>
nevermind i see now. frequency on the left and time on the right
<weirdtreething>
policy6/12 is spending all of its time at the maximum frequency
hexdump01 has joined #aarch64-laptops
<sibis928376>
hmm, then the only diff would be the frequencies at which the ddr/llcc are operating; this should be handled in the memlat series. Alternatively you can set ddr/llcc votes to max by disabling sync state in the interconnect drivers.
<weirdtreething>
I can give the series a try tomorrow
<weirdtreething>
I'll also go to the latest -next and see if anything changes there
rfs613 has quit [Ping timeout: 480 seconds]
hexdump0815 has quit [Ping timeout: 480 seconds]
dc7800 has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Remote host closed the connection]
<sibis928376>
steev: Will check and get back if cl4 is enough to get boost to kick in. Otherwise the schedutil patch will be a NOP; kernel would ensure schedutil votes for these turbo frequencies but the system never would reach these frequencies since the condition that all other cores need to be in idle would never be met.
<steev>
that would be amazing. i've lost count of how many tasty beverages you're "owed"
<sibis928376>
lol
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Remote host closed the connection]
blaztinn has quit [Remote host closed the connection]
blaztinn has joined #aarch64-laptops
bandini has joined #aarch64-laptops
Gnappo has joined #aarch64-laptops
<JensGlathe[m]>
sibis928376: yes I have reproduced that dc zva crash on x1e devkit. To get it stable/immune against it I had to additionally disable cpuidle, disabling cl5 was not enough. I wrote that in the patch, though
Acelogic_ has quit []
Acelogic_ has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Ping timeout: 480 seconds]
Acelogic_ has quit []
Acelogic_ has joined #aarch64-laptops
Acelogic_ has quit []
Acelogic_ has joined #aarch64-laptops
Acelogic_ has quit []
Acelogic_ has joined #aarch64-laptops
Acelogic_ has quit []
Acelogic_ has joined #aarch64-laptops
<HdkR>
The potential X2E minipc shipped. Very curious what it'll be
<JensGlathe[m]>
... to you I assume
<HdkR>
Hopefully anyway. Never know where it could end up :P
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
Gnappo has quit [Quit: Connection closed for inactivity]
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
antoinelassagne9 has joined #aarch64-laptops
antoinelassagne has quit [Read error: Connection reset by peer]
antoinelassagne9 is now known as antoinelassagne
Gnappo has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]