Skip to content

Configurable core count #2363

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

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

ahartmetz
Copy link
Contributor

Some nodes can run out of memory if all of their cores are used. There may be other reasons to limit the amount of cores used.

It seems to be a bad deal: increases line count and obscures the
origin of values in a pretty long function.
Problems:
- Will now show "extended" core count in scheduler instead of
  "true" core count
  - OTOH will not show more jobs than cores anymore, which
    was weird
- Job distribution still kinda sucks; what about
  - "full core" vs "SMT core" differences? (The second half of
    cores on a 2-way SMT CPU is usually only 10%-30% as fast as the
    first half)
  - Other effects, such as memory bandwith and thermal throttling,
    that make a core faster on a lightly loaded machine (though,
    seems to be typically a small effect of 10%..30% for compiler-
    type work)
  - CPU performance differences?
    - Ugh, would need a suitable benchmark load and some heuristics
      to get a usable result on a not-necessarily-unloaded machine
  - Automatic memory limiting? When running out of memory, stop
    all jobs except one and let them finish sequentially.
    - Any other ideas?
    - Maybe reduce job count temporarily as well? But when to lift
      the reduction then? It's all pretty messy!
    - Maybe kill the most memory-intensive job and send it to
      another machine, or the same machine after other jobs have
      all finished?
      - Actually! To guarantee progress, it's probably best to
        kill the youngest jobs first
        - But what if the youngest job is the one using the most
          memory...?
@codecov-commenter
Copy link

codecov-commenter commented Mar 14, 2025

Codecov Report

Attention: Patch coverage is 10.52632% with 34 lines in your changes missing coverage. Please review.

Project coverage is 67.51%. Comparing base (0cc0c62) to head (76945e4).
Report is 162 commits behind head on main.

Files with missing lines Patch % Lines
src/dist/http.rs 10.00% 18 Missing ⚠️
src/bin/sccache-dist/main.rs 0.00% 12 Missing ⚠️
src/config.rs 0.00% 4 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff             @@
##             main    #2363       +/-   ##
===========================================
+ Coverage   30.91%   67.51%   +36.60%     
===========================================
  Files          53       65       +12     
  Lines       20112    35460    +15348     
  Branches     9755        0     -9755     
===========================================
+ Hits         6217    23940    +17723     
- Misses       7922    11520     +3598     
+ Partials     5973        0     -5973     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@@ -430,6 +431,7 @@ impl DistSystem {
Some(SocketAddr::from(([0, 0, 0, 0], server_addr.port()))),
self.scheduler_url().to_url(),
token,
4,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it would be great if the test could verify that, indeed, 4 core are being used

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants