Status Update
No update yet.
Comments
cc...@google.com
Thanks for your detailed post.
However, benchmark build type is under configured: at least isProfileable is not set to true for existing build type, probably there's more.
We should set isProfileable = true by default when overriding an existing benchmark build type.
This issue is not about some specific configuration flag, but the general approach of dealing with external configuration. As a developer adopting baseline profiles, it seems extremely risky to me using a custom configuration due to how it's applied under the hood and the fact it may break default configuration.
I agree that is not great but this is a little tricky to do. For custom baseline profile build types we override all the properties. For benchmark I left it open to configure but it's mostly about these 2 properties:
isMinifyEnabled
isShrinkResources
I don't have a way to see if the user is setting them before overriding, so for this reason, I'd prefer not to. I agree with you that some other properties could be set by default to make this easier, i.e.:
isJniDebuggable = false
isDebuggable = false
isProfileable = true
The reason why I mentioned the release signing config in the beginning is because I want to use debug signing config.
In the specific of your issue, i.e. using a debug certificate can you override the benchmark and baseline profile setting? You should be able to do something like:
android {
buildTypes {
release { ... }
debug { ... }
benchmarkRelease {
...
signingConfig signingConfigs.debug
}
nonMinifiedRelease {
...
signingConfig signingConfigs.debug
}
}
}
Description
05-22 22:30:07.284 6029 6029 D Benchmark: cpu4 CoreDir(online=true, availableFreqs=[300000, 345600, 422400, 499200, 576000, 652800, 729600, 806400, 902400, 979200, 1056000, 1132800, 1190400, 1267200, 1344000, 1420800, 1497600, 1574400, 1651200, 1728000, 1804800, 1881600, 1958400, 2035200, 2112000, 2208000, 2265600, 2323200, 2342400, 2361600, 2457600], currentMinFreq=300000)
Looking at logcat, libperfmgr seems to be trying to change clocks, but failing a lot of the time:
05-22 22:30:11.954 806 2521 W libperfmgr: Failed to write to node: /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq with value: 1248000, fd: 10
05-22 22:30:11.954 806 2521 W libperfmgr: Failed to write to node: /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq with value: 1900800, fd: 11
05-22 22:30:11.954 806 2521 W libperfmgr: Failed to write to node: /sys/devices/system/cpu/cpu4/cpufreq/scaling_min_freq with value: 2457600, fd: 13
05-22 22:30:12.454 806 2521 W libperfmgr: Failed to write to node: /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq with value: 1248000, fd: 13
05-22 22:30:12.454 806 2521 W libperfmgr: Failed to write to node: /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq with value: 1900800, fd: 14
05-22 22:30:12.454 806 2521 W libperfmgr: Failed to write to node: /sys/devices/system/cpu/cpu4/cpufreq/scaling_min_freq with value: 2457600, fd: 10
Talked with wvw@, who mentioned they disable based on cpu governor, specifically cpu 0:
On walleye, we disable CPU 0 without bothering to set the governor. Fix is simply to set the governor even though we'll be disabling the CPU.
This issue will likely affect any devices with big cores numerically after little cores in the core list.