Describe the task
Currently, our long-running analysis jobs are implicitly multithreaded, but Bazel's scheduler assumes actions use only 1 thread by default unless told otherwise.
Because of this mismatch, Bazel will schedule multiple analysis jobs concurrently (scaling up to the number of available CPU cores). When several of these multithreaded jobs run side-by-side, they all try to hog all CPU resources.
This leads to severe performance impact, resulting in jobs being timed out by Bazel, as reported by users.
The task is to fix the thread limits so Bazel can accurately schedule and isolate these actions.
Scope
- Limit resource usage of per_file rule (1 thread should be sufficient)
- Make Bazel aware that monolithic targets use multiple threads (having monolithic jobs use a single thread is unviable, since it will result in a timeout)
Definition of Done
- per_file actions are explicitly limited to 1 thread.
- The monolithic rule gives estimations for its thread requirements to Bazel. (if possible also for remote execution)
Describe the task
Currently, our long-running analysis jobs are implicitly multithreaded, but Bazel's scheduler assumes actions use only 1 thread by default unless told otherwise.
Because of this mismatch, Bazel will schedule multiple analysis jobs concurrently (scaling up to the number of available CPU cores). When several of these multithreaded jobs run side-by-side, they all try to hog all CPU resources.
This leads to severe performance impact, resulting in jobs being timed out by Bazel, as reported by users.
The task is to fix the thread limits so Bazel can accurately schedule and isolate these actions.
Scope
Definition of Done