Improve max rss heuristic for lower memory macOS devices - #170
Conversation
|
Also, I have the feeling that Julia on macOS tends to somehow use "less memory" than on other operating systems (or maybe it's just how memory works in macOS), so the threshold should really be smaller than for the other OSes anyway |
|
I've noticed that the RSS value goes up way more and faster on jobs with fewer workers. I suspect that Apple's memory management "magic" has something to do with it. Maybe the compressor kicks in so we never reach the threshold but then the memory has to be compressed and decompressed constantly? |
|
I bumped so we shouldn't squash |
|
@giordano if you don't have any objections I'll merge and bump this |
giordano
left a comment
There was a problem hiding this comment.
No objections from me. I don't think this is a definitive solution (in my experience 2000 MiB may still be too high on GitHub Actions runners if you have 2 concurrent jobs), but it's going in the right direction. As you said elsewhere, we'll probably just need to document these memory shenanigans as there isn't a one-size-fits-all solution.
Pulls in JuliaTesting/ParallelTestRunner.jl#170 (better max-RSS heuristic on low-memory macOS). Drop the [sources] entry once v2.8.2 is registered. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This is the current heuristic in Metal.jl to prevent thrashing in CI, and experimenting with it in the LinearAlgebra CI seems to have cut 2-worker runs from 70 minutes (10 minutes slower than 1 worker runs) down to 34 minutes (25 minutes faster than 1 worker runs)