-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Try to fix missing libc++.so.1 errors in arm64 llvmaot perf run #88705
Conversation
Tagging subscribers to this area: @hoyosjs Issue Detailsnull
|
Tagging subscribers to this area: @directhex Issue Detailsnull
|
I think this passed on internal CI? @LoopedBard3 @DrewScoggins @caaavik-msft if y'all are happy, plz approve and merge |
Looking back into the internal run, there are a lot of errors in the format of:
Do you know what the impact of this is on the rest of the testing and do you happen to know a good fix? Thanks! |
I think generally "condition 'corlib' not met" means the corlib wasn't found in the searched locations. I'm not sure where it's being copied too & searched for. Do you want me to try & figure a fix for that here, or in another PR? |
Either works, if kept in this PR we could rename the PR to something like "Update MonoAOT perf flow". |
OK. What's the minimally complex way I can reproduce the errors locally? How can I get a folder which looks like what's trying to run on Helix and a copy of the command we're trying to execute on there? |
@LoopedBard3 I think other changes in the interim have dealt with the missing Can we determine where we stand, with this PR in as-is? |
I will do another run so we can see if the issue has been fixed in the CI. @directhex The last change that I think is needed for the PR is to add the same monoAOT build args changes to the perf-non-wasm-jobs.yml. |
I have started a test run here: https://dev.azure.com/dnceng/internal/_build/results?buildId=2230039&view=results |
FWIW, you can try #88917 as a fix for the browser-wasm failing job |
The corelib issue has been fixed, check discussion in dotnet/BenchmarkDotNet#2311. Currently, there is another issue with nuget package versions reported in dotnet/performance#3164. |
I don't see any cases in perf-non-wasm-jobs.yml which are clearly wrong (just a lot of things using defaults). Are there further failures happening, in that set of pipelines? |
I think this issue is linux-arm64 specific which is in: runtime/eng/pipelines/coreclr/perf_slow.yml Lines 156 to 173 in 1138b24
The |
I will do a test run to verify. I noticed that some changes were made to perf_job.yml and what not. We use perf_job.yml for both sets perf_slow and perf-non-wasm-jobs, so if these changes are compatible with how we are already building in perf-non-wasm-jobs we are good. |
The error may have been made by using the same perf_slow build args for the non-wasm jobs run. Trying a run with the currently working Wasm AOT Build args. |
The Mono AOT LLVM arm64 perf lanes are broken due to this. What else needs to get this merged ? |
@LoopedBard3 the Helix queue seems to be pretty backed up so the internal runs will keep timing out, can we clear the queue? |
@DrewScoggins @cincuranet Any thoughts? |
@LoopedBard3 I don't know whether we have knobs to clear the queue. |
@cincuranet you can ask dnceng on the First Responders channel, they have the knobs. |
OK, x64 seems to be good. I think there's still a failure condition in arm64 ( |
I think I'm going to try and eliminate MonoBundleLLVMOptimizer and MonoAOTBundleLLVMOptimizer entirely. It's such an odd switch to include. Either you want a functional LLVM AOT (with opt/llc included) or you don't. |
I'm going to do this IN ANOTHER PR, since I've actually been making progress with fixing issues in this PR with the existing properties. |
I'm declaring this "good enough for now" X64 https://dev.azure.com/dnceng/internal/_build/results?buildId=2238462&view=results ARM64 run isn't finished, but has at least some tests passing already so unblocks the failures:
|
No description provided.