Closed nickdesaulniers closed 4 years ago
looks like that timed out, too: https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/351058979
Hmmm my local builds aren’t timing out but it might be worth seeing if there is a significant regression in boot time from 5.7 to latest mainline.
it may be one of the kselftests regressing in runtime. (maybe more tests were added; maybe there's an unexpected regression)
This appears related to https://github.com/ClangBuiltLinux/boot-utils/pull/20. I tested an arm64 defconfig
+ common.config
at v5.7.
$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LLVM=1 O=out/arm64 distclean defconfig
$ scripts/kconfig/merge_config.sh -O out/arm64 -m out/arm64/.config ~/cbl/github/ci/configs/common.config
...
$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LLVM=1 O=out/arm64 olddefconfig Image.gz
-cpu cortex-a57
:
[ 15.626943] reboot: Power down
-cpu max
:
[ 134.659678] reboot: Power down
With GCC 10.1.0, I see a similar slow down.
-cpu cortex-a57
:
[ 15.596947] reboot: Power down
-cpu max
:
[ 115.585043] reboot: Power down
We should probably increase the timeout to 5m in that case.
Interesting measurements, thanks for taking those. cc @broonie , as a heads up, it seems that maybe emulation of PAC+BTI is relatively expensive in QEMU.
@nathanchance let me bump it to 5m for a CI run, then try to tighten it up once we have a run from TravisCI.
[ 227.350907] reboot: Power down
Could probably get away with 4m but I would rather stick with 5m so that we can be absolutely sure we timed out. Additionally, I think that it is worth mentioning in the comments why we increased the timeout. If you disagree, let me know and I'll approve this.
I think that it is worth mentioning in the comments why we increased the timeout.
Done.
Fixes: https://github.com/ClangBuiltLinux/linux/issues/1058 Signed-off-by: Nick Desaulniers ndesaulniers@google.com