CI: use free runner in dist-aarch64-msvc

[MarcoIeni]

similar to #133175

try-job: dist-aarch64-msvc

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[MarcoIeni]

@bors try

[bors]

⌛ Trying commit 0270580 with merge e47a940...

[bors]

☀️ Try build successful - checks-actions
Build commit: e47a940 (e47a940f0241f9c941fdd64f3e4ddbca740213c0)

[MarcoIeni]

@bors try

[bors]

⌛ Trying commit 0270580 with merge 652db1f...

[MarcoIeni]

The previous run took too long to build llvm. Hopefully the next run will be better because of a warm cache

[Kobzol]

r? @Kobzol

[bors]

☀️ Try build successful - checks-actions
Build commit: 652db1f (652db1fa797c10ea1d25463923ba0bff4a82a536)

[klensy]

sccache not used for that job, but we can try to build manually and apply it here (or not).

[MarcoIeni]

From the logs, I can see that we build llvm 4 times. The first 2 times is free. The other times take 52 minutes.

I guess we do this for PGO reasons. Maybe in this case we can't use a cache for LLVM, therefore we can't use a free runner. Kobzol, what do you think? 🤔

[klensy]

A don't see opt-dist, so there no pgo?

Ahh, there 2 targets, thats why, probably --target=aarch64-pc-windows-msvc,arm64ec-pc-windows-msvc

LLVM_TARGET_ARCH=aarch64
LLVM_TARGET_ARCH=x86_64

[Kobzol]

Yeah there should be no PGO in this job. We only do that for x64 Linux and Windows.

[MarcoIeni]

ok, interesting, thanks both!

I see two options here:

• split this job in two, each one for each target (I'm not sure if there are consequences such as publishing two times some tools 🙈)
• trying to setup llvm cache. But I'm not sure this would be enough since right now this job takes 3h 49 minutes. If we setup llvm cache, building llvm could go down to 10 minutes (from what I've seen). So 3h 49m - (52 - 10) * 2 = 2h 25m which is on the limit of what we can accept.

Anyway, setting llvm cache is already a win, even if we don't switch to free runners, because the large runner will run for less time. Can we setup llvm cache? If yes, how?

[klensy]

Weird, i see --enable-sccache enabled, but no output from it. I'll try run in #133033

[klensy]

Looked at both runs again: they both was on different image versions, so second one didn't reuse sccache, thats the reason.

compiler versions:
MSVC/14.41.34120
MSVC/14.42.34433

[MarcoIeni]

Thanks for looking into this, I will trigger bors try again. 👍

[MarcoIeni]

@bors try

[bors]

⌛ Trying commit 0270580 with merge 6d2cc49...

[bors]

☀️ Try build successful - checks-actions
Build commit: 6d2cc49 (6d2cc495b75bbccbcbda898335d8551e521fdc99)

[MarcoIeni]

Took 2h and 20m.
Jakub, imo this could be acceptable because it's under the average of 2h 30m. But it's near the limit of course.

Maybe we can merge it and monitor the auto builds in the next week?

[Kobzol]

I'd say the average is more like 3+ hours right now, based on Datadog metrics. So in that sense this duration should be fine.

[klensy]

Btw, is datadog filters out try builds internally? Because i see that data sent in try builds too.

[Kobzol]

It allows us to filter all of that, yeah. I was looking at just auto builds.

[MarcoIeni]

I'd say the average is more like 3+ hours right now, based on Datadog metrics. So in that sense this duration should be fine.

Great! I put this as ready for review.

I will review what jobs are the bottleneck after this is merged anyway 👍

[Kobzol]

@bors r+

[bors]

📌 Commit 0270580 has been approved by Kobzol

It is now in the queue for this repository.