Revert ineffective "drop DWARF from Windows Go test binary links" - #55058
Conversation
This reverts commit 078d86b (#54903). ### Motivation `-w` was measured inert against the failure it was meant to mitigate. The OOM is in Go's own linker, not mingw `ld`: all 25 `errno=1455` dumps in job 1951788199 sit in `loadlib` -> `LoadSyms` -> `preloadSyms`. `-w` suppresses `DwarfGenerateDebugSyms`, which runs after `loadlib`, and it does not shrink the linker input either, because the compiler emits DWARF into the object files regardless (`-dwarf` defaults to true). ### Describe how you validated your changes Windows VM, 20 GB commit ceiling, `GOMEMLIMIT=2560MiB`, 3 reps each of: ``` go test -p 8 -race -cover -covermode=atomic ./cmd/... ``` ``` without -w 2/3 OOM peaks 16,581-17,299 MB with -w 2/3 OOM peaks 16,768-17,240 MB ``` Per-phase linker heap on Linux, `-ldflags=-benchmark=mem`, `-race`: ``` Loadlib live DwarfGenerateDebugSyms alloc baseline 420.2 MB 412.9 MB -w 420.5 MB 0 ``` `Loadlib` is unchanged to within 0.3 MB, which is why the OOM rate does not move. ### Additional Notes `-w` does cut peak link heap by 19 percent on Linux, 637 MB to 518 MB, and costs no diagnostics because `pclntab` is untouched. That saving is real but sits on the **wrong side of the failing phase**. Capping build concurrency is what addresses the OOM: `-p 5` was 0/8 clean where `-p 8` was 3/3 OOM. Measured on a 20 GB bare host over `./cmd/...` without the `python` tag, so the ordering transfers but the absolute numbers are not CI's.
|
🎯 Code Coverage (details) 🔗 Commit SHA: 8364f54 | Docs | View more details | Give us feedback! |
Files inventory check summaryFile checks results against ancestor 3067dd1c: Results for datadog-agent_7.84.0~devel.git.269.8364f54.pipeline.131636651-1_amd64.deb:No change detected Results for datadog-iot-agent_7.84.0~devel.git.269.8364f54.pipeline.131636651-1_amd64.deb:No change detected |
Regression DetectorRegression Detector ResultsMetrics dashboard Baseline: 83ec016 Optimization Goals: ✅ No significant changes detected
|
| perf | experiment | goal | Δ mean % | Δ mean % CI | trials | links |
|---|---|---|---|---|---|---|
| ➖ | quality_gate_metrics_logs | memory utilization | +0.31 | [+0.09, +0.53] | 1 | Logs bounds checks dashboard |
| ➖ | quality_gate_security_no_fs_load | memory utilization | +0.22 | [+0.13, +0.30] | 1 | Logs bounds checks dashboard |
| ➖ | quality_gate_security_idle | memory utilization | +0.01 | [-0.05, +0.06] | 1 | Logs bounds checks dashboard |
| ➖ | quality_gate_idle | memory utilization | +0.00 | [-0.04, +0.05] | 1 | Logs bounds checks dashboard |
| ➖ | quality_gate_idle_all_features | memory utilization | -0.06 | [-0.10, -0.03] | 1 | Logs bounds checks dashboard |
| ➖ | quality_gate_logs | % cpu utilization | -0.08 | [-0.95, +0.80] | 1 | Logs bounds checks dashboard |
| ➖ | quality_gate_security_mean_fs_load | memory utilization | -0.10 | [-0.14, -0.07] | 1 | Logs bounds checks dashboard |
| ➖ | quality_gate_private_action_runner | memory utilization | -0.40 | [-0.52, -0.27] | 1 | Logs bounds checks dashboard |
Bounds Checks: ✅ Passed
| perf | experiment | bounds_check_name | replicates_passed | observed_value | links |
|---|---|---|---|---|---|
| ✅ | quality_gate_idle | intake_connections | 10/10 | 4 = 4 | bounds checks dashboard |
| ✅ | quality_gate_idle | memory_usage | 10/10 | 172.21MiB ≤ 178MiB | bounds checks dashboard |
| ✅ | quality_gate_idle | total_bytes_received | 10/10 | 745.38KiB ≤ 819.20KiB | bounds checks dashboard |
| ✅ | quality_gate_idle_all_features | intake_connections | 10/10 | 4 = 4 | bounds checks dashboard |
| ✅ | quality_gate_idle_all_features | memory_usage | 10/10 | 513.69MiB ≤ 538MiB | bounds checks dashboard |
| ✅ | quality_gate_idle_all_features | total_bytes_received | 10/10 | 1.14MiB ≤ 1.25MiB | bounds checks dashboard |
| ✅ | quality_gate_logs | intake_connections | 10/10 | 19 ≤ 40 | bounds checks dashboard |
| ✅ | quality_gate_logs | memory_usage | 10/10 | 210.00MiB ≤ 229MiB | bounds checks dashboard |
| ✅ | quality_gate_logs | missed_bytes | 10/10 | 0B = 0B | bounds checks dashboard |
| ✅ | quality_gate_logs | total_bytes_received | 10/10 | 263.43MiB ≤ 292MiB | bounds checks dashboard |
| ✅ | quality_gate_metrics_logs | cpu_usage | 10/10 | 386.48 ≤ 2000 | bounds checks dashboard |
| ✅ | quality_gate_metrics_logs | intake_connections | 10/10 | 20 ≤ 40 | bounds checks dashboard |
| ✅ | quality_gate_metrics_logs | memory_usage | 10/10 | 412.37MiB ≤ 439MiB | bounds checks dashboard |
| ✅ | quality_gate_metrics_logs | missed_bytes | 10/10 | 0B = 0B | bounds checks dashboard |
| ✅ | quality_gate_metrics_logs | total_bytes_received | 10/10 | 0.94GiB ≤ 1.04GiB | bounds checks dashboard |
| ✅ | quality_gate_private_action_runner | memory_usage | 10/10 | 71.36MiB ≤ 76MiB | bounds checks dashboard |
| ✅ | quality_gate_security_idle | cpu_usage | 10/10 | 32.47 ≤ 100 | bounds checks dashboard |
| ✅ | quality_gate_security_idle | memory_usage | 10/10 | 327.14MiB ≤ 335MiB | bounds checks dashboard |
| ✅ | quality_gate_security_mean_fs_load | cpu_usage | 10/10 | 67.23 ≤ 200 | bounds checks dashboard |
| ✅ | quality_gate_security_mean_fs_load | memory_usage | 10/10 | 303.74MiB ≤ 314MiB | bounds checks dashboard |
| ✅ | quality_gate_security_no_fs_load | cpu_usage | 10/10 | 23.87 ≤ 100 | bounds checks dashboard |
| ✅ | quality_gate_security_no_fs_load | memory_usage | 10/10 | 312.16MiB ≤ 343MiB | bounds checks dashboard |
Explanation
Confidence level: 90.00%
Effect size tolerance: |Δ mean %| ≥ 5.00%
Performance changes are noted in the perf column of each table:
- ✅ = significantly better comparison variant performance
- ❌ = significantly worse comparison variant performance
- ➖ = no significant change in performance
A regression test is an A/B test of target performance in a repeatable rig, where "performance" is measured as "comparison variant minus baseline variant" for an optimization goal (e.g., ingress throughput). Due to intrinsic variability in measuring that goal, we can only estimate its mean value for each experiment; we report uncertainty in that value as a 90.00% confidence interval denoted "Δ mean % CI".
For each experiment, we decide whether a change in performance is a "regression" -- a change worth investigating further -- if all of the following criteria are true:
-
Its estimated |Δ mean %| ≥ 5.00%, indicating the change is big enough to merit a closer look.
-
Its 90.00% confidence interval "Δ mean % CI" does not contain zero, indicating that if our statistical model is accurate, there is at least a 90.00% chance there is a difference in performance between baseline and comparison variants.
-
Its configuration does not mark it "erratic".
CI Pass/Fail Decision
✅ Passed. All Quality Gates passed.
- quality_gate_security_mean_fs_load, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_security_mean_fs_load, bounds check cpu_usage: 10/10 replicas passed. Gate passed.
- quality_gate_idle, bounds check intake_connections: 10/10 replicas passed. Gate passed.
- quality_gate_idle, bounds check total_bytes_received: 10/10 replicas passed. Gate passed.
- quality_gate_idle, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_logs, bounds check total_bytes_received: 10/10 replicas passed. Gate passed.
- quality_gate_logs, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_logs, bounds check missed_bytes: 10/10 replicas passed. Gate passed.
- quality_gate_logs, bounds check intake_connections: 10/10 replicas passed. Gate passed.
- quality_gate_security_idle, bounds check cpu_usage: 10/10 replicas passed. Gate passed.
- quality_gate_security_idle, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_security_no_fs_load, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_security_no_fs_load, bounds check cpu_usage: 10/10 replicas passed. Gate passed.
- quality_gate_private_action_runner, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_metrics_logs, bounds check cpu_usage: 10/10 replicas passed. Gate passed.
- quality_gate_metrics_logs, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_metrics_logs, bounds check total_bytes_received: 10/10 replicas passed. Gate passed.
- quality_gate_metrics_logs, bounds check missed_bytes: 10/10 replicas passed. Gate passed.
- quality_gate_metrics_logs, bounds check intake_connections: 10/10 replicas passed. Gate passed.
- quality_gate_idle_all_features, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_idle_all_features, bounds check intake_connections: 10/10 replicas passed. Gate passed.
- quality_gate_idle_all_features, bounds check total_bytes_received: 10/10 replicas passed. Gate passed.
Static quality checks✅ Please find below the results from static quality gates Successful checksInfo
|
<!-- dd-meta
{"pullId":"00000000-0000-0000-0000-000000000000","source":"chat","resourceId":"d22710d1-5882-4f45-b143-ab633d2a3bab","workflowId":"68794ae9-c0a1-4c8e-a8c6-687f8307a48e","codeChangeId":"68794ae9-c0a1-4c8e-a8c6-687f8307a48e","sourceType":"slack"}
-->
<!--Please give us some feedback on your experience writing this PR !
https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88
!-->
### What does this PR do?
- Adds `DD_BAZEL_TEST_JOBS` support for hybrid Bazel test runs.
- Caps `tests_windows-x64` hybrid Bazel test concurrency at `--jobs=4`.
- Documents the Windows Bazel Go test linker-memory mitigation.
- Adds unit coverage for the Bazel jobs cap selection and command-line
injection.
### Motivation
`tests_windows-x64` intermittently fails on main with Windows
`VirtualAlloc ... errno=1455` and linker memory exhaustion while
building large race/cgo Go test binaries. The legacy Go test path is
being capped separately in #55054. This PR handles the separate Bazel
test phase by limiting Bazel test concurrency in the Windows CI job.
Review feedback and measurements in #55044/#55058 showed that the
earlier `-w`/DWARF stripping experiment was low-value and confusing for
developers, so this PR no longer changes Bazel linker flags.
### Describe how you validated your changes
- `dda inv invoke-unit-tests --tests=go --directory=tasks/unit_tests`
- `bazel query //bazel/tools/coverage:coverage_test`
- `git diff --check`
### Additional Notes
`DD_BAZEL_TEST_JOBS` remains configurable if the Windows CI cap needs
future tuning. The cap composes with #55054 because the legacy Go test
phase completes before the Bazel test phase starts.
---
PR by Bits - [View session in
Datadog](https://app.datadoghq.com/code/d22710d1-5882-4f45-b143-ab633d2a3bab)
Comment @DataDog to request changes
---------
Co-authored-by: datadog-bits <[email protected]>
Co-authored-by: chouetz <[email protected]>
3b6d902
into
main
…5058) This reverts commit 078d86b (#54903). ### Motivation `-w` was measured inert against the failure it was meant to mitigate. The OOM is in Go's own linker, not mingw `ld`: all 25 `errno=1455` dumps in job [1951788199](https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1951788199) sit in `loadlib` -> `LoadSyms` -> `preloadSyms`. `-w` suppresses `DwarfGenerateDebugSyms`, which runs after `loadlib`, and it does not shrink the linker input either, because the compiler emits DWARF into the object files regardless (`-dwarf` defaults to true). ### Describe how you validated your changes Windows VM, 20 GB commit ceiling, `GOMEMLIMIT=2560MiB`, 3 reps each of: ``` go test -p 8 -race -cover -covermode=atomic ./cmd/... ``` ``` without -w 2/3 OOM peaks 16,581-17,299 MB with -w 2/3 OOM peaks 16,768-17,240 MB ``` Per-phase linker heap on Linux, `-ldflags=-benchmark=mem`, `-race`: ``` Loadlib live DwarfGenerateDebugSyms alloc baseline 420.2 MB 412.9 MB -w 420.5 MB 0 ``` `Loadlib` is unchanged to within 0.3 MB, which is why the OOM rate does not move. ### Additional Notes `-w` does cut peak link heap by 19 percent on Linux, 637 MB to 518 MB, and costs no diagnostics because `pclntab` is untouched. That saving is real but sits on the **wrong side of the failing phase**. Capping build concurrency is what addresses the OOM: `-p 5` was 0/8 clean where `-p 8` was 3/3 OOM, hence: - #55054. Measured on a 20 GB bare host over `./cmd/...` without the `python` tag, so the ordering transfers but the absolute numbers are not CI's. Co-authored-by: regis.desgroppes <[email protected]> 3b6d902
This reverts commit 078d86b (#54903).
Motivation
-wwas measured inert against the failure it was meant to mitigate.The OOM is in Go's own linker, not mingw
ld: all 25errno=1455dumps in job 1951788199 sit inloadlib->LoadSyms->preloadSyms.-wsuppressesDwarfGenerateDebugSyms, which runs afterloadlib, and it does not shrink the linker input either, because the compiler emits DWARF into the object files regardless (-dwarfdefaults to true).Describe how you validated your changes
Windows VM, 20 GB commit ceiling,
GOMEMLIMIT=2560MiB, 3 reps each of:Per-phase linker heap on Linux,
-ldflags=-benchmark=mem,-race:Loadlibis unchanged to within 0.3 MB, which is why the OOM rate does not move.Additional Notes
-wdoes cut peak link heap by 19 percent on Linux, 637 MB to 518 MB, and costs no diagnostics becausepclntabis untouched.That saving is real but sits on the wrong side of the failing phase.
Capping build concurrency is what addresses the OOM:
-p 5was 0/8 clean where-p 8was 3/3 OOM, hence:tests_windows-x64build parallelism at 4 #55054.Measured on a 20 GB bare host over
./cmd/...without thepythontag, so the ordering transfers but the absolute numbers are not CI's.