ci: Optimizing costs for AWS self-hosted runners

[sampra2025]

With this update, the AWS self-hosted runner instance type will change from "c5ad.8xlarge" to "m8a.4xlarge". This adjustment will improve build performance by at least 20% and lower the hourly cost by 30%.

The runner instance has been tested in the Stage environment. For reference, here is a sample build workflow:
https://github.com/qualcomm-linux-stg/aws-meta-qcom/actions/runs/20283368465

[lumag]

Please start your commit message by describing the issue that you are fixing. Then continue with describing what has to be done. Don't describe patch contents, it's obvious from the patch itself.

[ndechesne]

I am actually surprised by the results, I was expecting the ssd. to have a bigger impact, but if we save time and money, sure. Can we run a few more comparative tests?

[lumag]

Commit message is even more weirdly formatted and it still doesn't describe the reasons for the change. Please start by describing the problem, then describe the solution. Avoid phrases like "This change" or "This patch".

[ricardosalveti]

I am actually surprised by the results, I was expecting the ssd. to have a bigger impact, but if we save time and money, sure. Can we run a few more comparative tests?

Yeah, curious if it will also be better on a clean build, without any previous sstate cache.

[sampra2025]

I am actually surprised by the results, I was expecting the ssd. to have a bigger impact, but if we save time and money, sure. Can we run a few more comparative tests?

Yeah, curious if it will also be better on a clean build, without any previous sstate cache.

Thank you for your feedback. With the recent build, we are seeing similar performance. I agree that running a clean build is a good idea. Please let me know the best approach for running a clean build.

[github-actions]

Test run workflow

Test jobs for commit b627afa

• Job 130736 on qcs8300 - meta-qcom-qcom-distro-20759254373-1-boot test
• Job 130727 on qcs9100 - meta-qcom-qcom-distro-20759254373-1-boot test
• Job 130738 on dragonboard-820c - meta-qcom-qcom-distro-20759254373-1-boot test
• Job 130735 on qrb2210-rb1 - meta-qcom-qcom-distro-20759254373-1-boot test
• Job 130733 on qcs9100-rb8 - meta-qcom-qcom-distro-20759254373-1-boot test
• Job 130739 on dragonboard-820c - meta-qcom-qcom-distro-20759254373-1-boot test
• Job 130737 on qcs8300 - meta-qcom-qcom-distro-20759254373-1-boot test
• Job 130732 on qcs9100 - meta-qcom-qcom-distro-20759254373-1-boot test
• Job 130734 on qrb2210-rb1 - meta-qcom-qcom-distro-20759254373-1-boot test
• Job 130740 on qcs6490 - meta-qcom-qcom-distro-20759254373-1-boot test
• Job 130728 on qcs9100-rb8 - meta-qcom-qcom-distro-20759254373-1-boot test
• Job 130729 on qcs6490 - meta-qcom-qcom-distro-20759254373-1-boot test
• Job 130731 on dragonboard-410c - meta-qcom-qcom-distro-20759254373-1-boot test
• Job 130730 on dragonboard-410c - meta-qcom-qcom-distro-20759254373-1-boot test

[test-reporting-app]

Test Results

11 files   -   8  11 suites   - 57   18m 26s ⏱️ - 39m 11s
11 tests  -  25  11 ✅  -  25  0 💤 ±0  0 ❌ ±0 
89 runs   - 566  89 ✅  - 563  0 💤  - 3  0 ❌ ±0 

Results for commit b627afa. ± Comparison against base commit 19a15a0.

This pull request removes 25 tests.

0_hotplug ‑ hotplug
1_CPUFreq_Validation ‑ CPUFreq_Validation
2_Interrupts ‑ Interrupts
3_cdsp_remoteproc ‑ cdsp_remoteproc
4_adsp_remoteproc ‑ adsp_remoteproc
5_WiFi_Firmware_Driver ‑ WiFi_Firmware_Driver
6_WiFi_OnOff ‑ OpenCV
6_WiFi_OnOff ‑ WiFi_OnOff
7_OpenCV ‑ OpenCV
8_irq ‑ irq
…

[ricardosalveti]

Thank you for your feedback. With the recent build, we are seeing similar performance. I agree that running a clean build is a good idea. Please let me know the best approach for running a clean build.

In your staging environment you can just erase the sstate cache entirely before doing a new build with both worker types, then can easily compare.

[sampra2025]

Thank you for your feedback. With the recent build, we are seeing similar performance. I agree that running a clean build is a good idea. Please let me know the best approach for running a clean build.

In your staging environment you can just erase the sstate cache entirely before doing a new build with both worker types, then can easily compare.

Great.. I will do it in stage environment and share the result with you.

[sampra2025]

I am actually surprised by the results, I was expecting the ssd. to have a bigger impact, but if we save time and money, sure. Can we run a few more comparative tests?

Yeah, curious if it will also be better on a clean build, without any previous sstate cache.

Thank you for your feedback. With the recent build, we are seeing similar performance. I agree that running a clean build is a good idea. Please let me know the best approach for running a clean build.

I have completed a clean build after removing the sstate cache. Here is the link for your reference. Please share your feedback.
https://github.com/qualcomm-linux-stg/aws-meta-qcom/actions/runs/20768000476

Note: There are four revisions of builds for this workflow. The latest revision is after removing the sstate cache, while the first revision was done before its removal.

[ricardosalveti]

Do you have a similar run but using the old runner instead in hands?

[ricardosalveti]

We're facing way too many build issues (segfault, could be caused by oom), let's switch and validate it helps the current situation.