tagger: handle GPU tags #32052
tagger: handle GPU tags #32052
Conversation
Test changes on VMUse this command from test-infra-definitions to manually test this PR changes on a VM: inv aws.create-vm --pipeline-id=52815211 --os-family=ubuntuNote: This applies to commit af537d2 |
Package size comparisonComparison with ancestor Diff per package
Decision |
gjulianm
force-pushed
the
guillermo.julian/gpu-workloadmeta
branch
from
3511c39 to
ec6d319
Compare
gjulianm
force-pushed
the
guillermo.julian/gpu-wmeta-tagger
branch
from
bfbf39d to
49cb49b
Compare
github-actions
bot
added
team/container-platform
gjulianm
added
changelog/no-changelog
qa/done
Uncompressed package size comparisonComparison with ancestor Diff per package
Decision |
Regression DetectorRegression Detector ResultsMetrics dashboard Baseline: a55d195 Optimization Goals: ✅ No significant changes detected
|
| perf | experiment | goal | Δ mean % | Δ mean % CI | trials | links |
|---|---|---|---|---|---|---|
| ➖ | file_to_blackhole_1000ms_latency | egress throughput | +1.06 | [+0.27, +1.85] | 1 | Logs |
| ➖ | file_tree | memory utilization | +0.49 | [+0.35, +0.62] | 1 | Logs |
| ➖ | uds_dogstatsd_to_api_cpu | % cpu utilization | +0.29 | [-0.42, +1.00] | 1 | Logs |
| ➖ | file_to_blackhole_0ms_latency_http1 | egress throughput | +0.12 | [-0.73, +0.97] | 1 | Logs |
| ➖ | file_to_blackhole_100ms_latency | egress throughput | +0.08 | [-0.66, +0.81] | 1 | Logs |
| ➖ | file_to_blackhole_0ms_latency_http2 | egress throughput | +0.03 | [-0.86, +0.93] | 1 | Logs |
| ➖ | tcp_dd_logs_filter_exclude | ingress throughput | -0.00 | [-0.01, +0.01] | 1 | Logs |
| ➖ | file_to_blackhole_0ms_latency | egress throughput | -0.00 | [-0.86, +0.86] | 1 | Logs |
| ➖ | uds_dogstatsd_to_api | ingress throughput | -0.00 | [-0.11, +0.10] | 1 | Logs |
| ➖ | file_to_blackhole_300ms_latency | egress throughput | -0.01 | [-0.65, +0.62] | 1 | Logs |
| ➖ | quality_gate_idle | memory utilization | -0.09 | [-0.13, -0.05] | 1 | Logs bounds checks dashboard |
| ➖ | file_to_blackhole_1000ms_latency_linear_load | egress throughput | -0.14 | [-0.61, +0.33] | 1 | Logs |
| ➖ | quality_gate_idle_all_features | memory utilization | -0.24 | [-0.33, -0.16] | 1 | Logs bounds checks dashboard |
| ➖ | file_to_blackhole_500ms_latency | egress throughput | -0.30 | [-1.07, +0.47] | 1 | Logs |
| ➖ | tcp_syslog_to_blackhole | ingress throughput | -0.90 | [-0.97, -0.83] | 1 | Logs |
| ➖ | quality_gate_logs | % cpu utilization | -1.21 | [-4.36, +1.93] | 1 | Logs |
Bounds Checks: ✅ Passed
| perf | experiment | bounds_check_name | replicates_passed | links |
|---|---|---|---|---|
| ✅ | file_to_blackhole_0ms_latency | lost_bytes | 10/10 | |
| ✅ | file_to_blackhole_0ms_latency | memory_usage | 10/10 | |
| ✅ | file_to_blackhole_0ms_latency_http1 | lost_bytes | 10/10 | |
| ✅ | file_to_blackhole_0ms_latency_http1 | memory_usage | 10/10 | |
| ✅ | file_to_blackhole_0ms_latency_http2 | lost_bytes | 10/10 | |
| ✅ | file_to_blackhole_0ms_latency_http2 | memory_usage | 10/10 | |
| ✅ | file_to_blackhole_1000ms_latency | memory_usage | 10/10 | |
| ✅ | file_to_blackhole_1000ms_latency_linear_load | memory_usage | 10/10 | |
| ✅ | file_to_blackhole_100ms_latency | lost_bytes | 10/10 | |
| ✅ | file_to_blackhole_100ms_latency | memory_usage | 10/10 | |
| ✅ | file_to_blackhole_300ms_latency | lost_bytes | 10/10 | |
| ✅ | file_to_blackhole_300ms_latency | memory_usage | 10/10 | |
| ✅ | file_to_blackhole_500ms_latency | lost_bytes | 10/10 | |
| ✅ | file_to_blackhole_500ms_latency | memory_usage | 10/10 | |
| ✅ | quality_gate_idle | memory_usage | 10/10 | bounds checks dashboard |
| ✅ | quality_gate_idle_all_features | memory_usage | 10/10 | bounds checks dashboard |
| ✅ | quality_gate_logs | lost_bytes | 10/10 | |
| ✅ | quality_gate_logs | memory_usage | 10/10 |
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_idle, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_idle_all_features, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_logs, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_logs, bounds check lost_bytes: 10/10 replicas passed. Gate passed.
|
Can you please also update the README.md by adding the gpu entity id to the table of entity ids. |
|
I don't think unit tests are enough to add Could you please do one of the following:
|
|
Added the entry to the README.md I'll add e2e tests, but in that case I need to wait for #32109 to get merged, and change how we add tags in the GPU check. |
If I understand correctly, as long as wlm PR is not merged, merging the current PR has no functional change. If my understanding is correct, E2E tests should be part of the other PR WDYT? |
|
Makes sense. We could merge this PR before the other then? The only thing is that the e2e tests would be split in two PRs:
|
Presence of GPU entities in WMS is an internal implementation detail. E2E tests should not test internal implementation details, they should test E2E functionality considering the agent as a black box. In our case, what E2E tests should assert should be something like this: Run the agent on a node with nvidia gpu, and assert that the GPU metrics are properly tagged with GPU tags. This is what the end user will see, and hence it is what should be tested in E2E. So bottom line is we only need to add E2E once to cover both PRs. Internal details can be covered with unit tests. |
In that case I can add the E2E tests to the PR changing the GPU check to use tags, and marking this PR as |
|
Sounds good Regarding the README.md, I think you missed pushing the change. Could you please push it so I can approve? |
|
Pushed, I did forget to push, sorry :D |
gjulianm
removed
the
qa/done
adel121
added
the
qa/rc-required
|
/merge |
Devflow running:
|
What does this PR do?
This PR adds handling of GPU entities to the tagger.
Motivation
Unify the tags for GPU devices
https://datadoghq.atlassian.net/browse/EBPF-599
Describe how you validated your changes
Unit tests included in the changes. E2E tests will be included in #32906 and #32109 when the corresponding checks use this new feature.
Possible Drawbacks / Trade-offs
Additional Notes
Related to #32019