This repository has been archived by the owner on Aug 8, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We started to see the
System.Core-xunit
step on CI to hit the timeout of 15 minutes with Linux/ARM64. That was weird, because the step used to be completed in around two minutes. With my local device (jetson board) I wasn't able to reproduce it either; it took around 100s there. We then realized it's specific to the newtaishan
CI machines, which are equipped with 64 cores. Hardcodingmono_cpu_count
to return 16 restored the performance, however that isn't a viable fix.Limiting
DefaultDegreeOfParallelism
to 16 fixes it, which is less extreme than limitingmono_cpu_count ()
, still not ideal though. It seems to boil down to the fact that our non-netcore threadpool implementation doesn't handle a large number of cores well.repro.cs
, extracted from here https://github.com/dotnet/corefx/blob/a9b91e205a8794327a028cb4b29953127f0f194c/src/System.Linq.Parallel/tests/QueryOperators/ConcatTests.cs#L145-L154Before fix:
With this fix:
/cc @akoeplinger @lambdageek @filipnavara